1 |
2011/6/27 Wyatt Epp <wyatt.epp@×××××.com>: |
2 |
> 2011/6/27 Jesús J. Guerrero Botella <jesus.guerrero.botella@×××××.com>: |
3 |
>> That still doesn't answer my question anyway: both features (symlinks |
4 |
>> and +65k files on a single dir) are incompatible with fat32. And |
5 |
>> someone said fat32 compatibility is a feature we want (still can't |
6 |
>> guess why, but well, be consequent...). Obviously, we want fat32 |
7 |
>> compatibility when it comes to arguing against symlinks, which have |
8 |
>> always been with us by the way, but that's not important when we talk |
9 |
>> about other things that are not compatible with fat32. |
10 |
> |
11 |
> I'm not sure where you're getting 65k files. Unless I misinterpreted |
12 |
> everything everyone else was saying, every package would still have |
13 |
> its own directory. There are fewer than 20k even with a bunch of |
14 |
> overlays installed. Regardless, you might check the other (other) |
15 |
> thread; I think we're probably going to go quick and |
16 |
> not-necessarily-dirty with sets to get 99% of what we're looking for |
17 |
> almost trivially. |
18 |
|
19 |
Well, someone suggested a flat directory, which I understand as having |
20 |
all the ebuilds in a single directory, that's also why they are |
21 |
talking about the need to make ebuild names unique, to avoid file |
22 |
names collision. |
23 |
|
24 |
> 2011/6/27 Jesús J. Guerrero Botella <jesus.guerrero.botella@×××××.com>: |
25 |
>> C) "ls $PORTDIR/whatever-category" is a command that's way simpler |
26 |
>> than the one you posted. |
27 |
>> |
28 |
> It's also fundamentally broken because one package can only be in one |
29 |
> category and their expansion has not historically been speedy. Tags |
30 |
> are a non-exclusive one-to-many relationship. So a package can have |
31 |
> as many tags as it needs, and users will be able to leverage tags |
32 |
> alone or in combinations to find things they want or need. |
33 |
|
34 |
I wouldn't call that broken. Again, symlinks can perfectly solve that |
35 |
with little extra work. We use them for that same purpose in lots of |
36 |
things. For example, eselect sets symlinks to select the active mesa |
37 |
implementation from between all the installed ones. And we have been |
38 |
using symlinks to make libs and paths available with different names |
39 |
in linux fs's since ever. |
40 |
|
41 |
I am not saying that my idea is better than the rest. I am just |
42 |
wondering why the heck symlinks are not an option when linux has |
43 |
supported them natively since almost the day zero. |
44 |
|
45 |
>> I don't even use tags for my music collections |
46 |
> |
47 |
> That's very curious, and I wouldn't mind talking about why that is |
48 |
> off-list (not quite joking; that's really interesting). |
49 |
|
50 |
Feel free to mail me if you want extra clarification. But to sum up, I |
51 |
just keep everything in a estructured directory tree. I could easily |
52 |
use easytag to automatically tag everything with little or not extra |
53 |
effort, automatically, but I rarely resort to tags. I don't use |
54 |
behemoths like amarok or the likes. I use mplayer or moc, usually. And |
55 |
locate is the only tool I need to find quickly a song in less than one |
56 |
second. |
57 |
|
58 |
> So to sum it up, we're fixing package navigation and discovery because |
59 |
> Gentoo is about choice. Even 15,000 packages is too many to have to |
60 |
> play "guess the category", and it's cruel to expect users (including |
61 |
> ourselves) to know everything in the tree at all times. It's in all |
62 |
> our best interest to make it easy to know what choices are available |
63 |
> so we can get back to more important things. Tags help further this |
64 |
> ideal. |
65 |
|
66 |
That's fine by me, as long as some sense is retained in the underlying |
67 |
fs estructure and tags are an added value, not a substitute for what's |
68 |
already in there. What I wouldn't like is to get 140k ebuilds dumped |
69 |
into a single directory. |
70 |
|
71 |
|
72 |
-- |
73 |
Jesús Guerrero Botella |