1 |
2011/6/27 Zac Medico <zmedico@g.o>: |
2 |
> On 06/24/2011 12:52 AM, Jesús J. Guerrero Botella wrote: |
3 |
>> 2011/6/24 Zac Medico <zmedico@g.o>: |
4 |
>>> On 06/22/2011 11:15 PM, Jesús J. Guerrero Botella wrote: |
5 |
>>>> Symlinks are clean, and portage has |
6 |
>>>> always been file-oriented so I see no problem with using them for |
7 |
>>>> this. All we need is to deference the symlink to find the real name of |
8 |
>>>> the package and put it in world instead of the symlinked name, so the |
9 |
>>>> rest of packages won't even need to be retouched to fix the |
10 |
>>>> dependencies. I don't really know if it's that simple as it sounds, |
11 |
>>>> but it's an idea. |
12 |
>>> |
13 |
>>> For some reason, using symlinks to represent tags seems like an odd |
14 |
>>> approach to me. I think it would be much more sensible to put them in |
15 |
>>> metadata.xml or an ebuild variable. If for some reason you want symlinks |
16 |
>>> representing the tags (I don't know why you would), you can always use a |
17 |
>>> script to generate symlinks from metadata.xml files. |
18 |
>> |
19 |
>> You might not like it, but Gentoo categories have always been |
20 |
>> directories, not words into metadata.xml. Most portage tools rely on |
21 |
>> that. Not a strong argument, I know that. But someone used this |
22 |
>> argument when someone else wanted to put portage into a database |
23 |
>> instead of an fs-based tree. That was long ago, admittedly, don't know |
24 |
>> if that conversation ever came up again. |
25 |
> |
26 |
> I see, so you want to optimize the tree layout for use with simple shell |
27 |
> commands. For a shell-friendly alternative to metadata.xml, I suppose |
28 |
> that we could instead use a plain text file called "tags" in the same |
29 |
> directory as metadata.xml. If it listed one tag per line, you could use |
30 |
> a simple shell command like this to search for packages with a specific tag: |
31 |
> |
32 |
> find /usr/portage -name tags | xargs grep <tag name> |
33 |
|
34 |
I still don't understand why |
35 |
|
36 |
A) you need to build a project, a glep, whatever the course of action |
37 |
is, I am bad at bureaucracy. |
38 |
B) you need to code the solution, to fix What? |
39 |
C) "ls $PORTDIR/whatever-category" is a command that's way simpler |
40 |
than the one you posted. |
41 |
|
42 |
XML seems to be the trend, but we should really think a moment, what's |
43 |
what we are trying to fix? |
44 |
|
45 |
We just needed to add some categories or rename them when someone |
46 |
started this thread, but now, even when we know we are lacking dev |
47 |
power in some areas we start arguing that the base concept of our OS |
48 |
(portage) is wrong, and that we should redo it completely by putting |
49 |
every ebuild into a directory and tagging them. Again, that's not |
50 |
"port-age". Read on ports: |
51 |
|
52 |
http://en.wikipedia.org/wiki/FreeBSD_Ports |
53 |
|
54 |
I don't even use tags for my music collections and now I am going to |
55 |
be forced to use them to operate my OS. We might even end having |
56 |
something like |
57 |
|
58 |
<portage> |
59 |
<ebuild> |
60 |
....................... |
61 |
</ebuild> |
62 |
<ebuild> |
63 |
....................... |
64 |
</ebuild> |
65 |
.. |
66 |
. |
67 |
. |
68 |
. |
69 |
. |
70 |
|
71 |
</portage> |
72 |
|
73 |
:P |
74 |
|
75 |
Or |
76 |
|
77 |
<fs> |
78 |
<dir>boot</dir> |
79 |
<dir>usr</dir> |
80 |
<dir>lib</dir> |
81 |
<dir>home</dir> |
82 |
</fs> |
83 |
|
84 |
genpatches could also remove symlink stuff from the kernel, since it's |
85 |
taking precious memory that could be used for the /proc.xml file. Yes, |
86 |
feeling sarcastic, but I am really trying to understand what's what we |
87 |
need to fix today. |
88 |
|
89 |
-- |
90 |
Jesús Guerrero Botella |