1 |
On Saturday 25 of June 2011 17:19:47 Duncan wrote: |
2 |
> Maciej Mrozowski posted on Sat, 25 Jun 2011 13:55:40 +0200 as excerpted: |
3 |
> > On Friday 24 of June 2011 09:55:19 Ciaran McCreesh wrote: |
4 |
> >> So tags are in some way related to categories then? |
5 |
> > |
6 |
> > IMHO the best approach is to forget about categories and: |
7 |
> > |
8 |
> > - make package names unique identifiers (it's not that hard, renaming |
9 |
> > stuff in app-xemacs mostly) - categories would serve no purpose as id |
10 |
> > anymore (though may need to be provided as backward compatibility - but |
11 |
> > with symlinks to ebuilds/${PN} inside) |
12 |
> |
13 |
> What a beautiful bikeshed we're debating! =:^p |
14 |
|
15 |
No bikeshedding, just any mean necessary (I'd be fine with anything) in order |
16 |
to phase out categories from being necessary for critical package manager |
17 |
operations. |
18 |
|
19 |
> > - move such packages into ${PORTDIR}/ebuilds directory (so that identity |
20 |
> > is ensured on filesystem level) - 'ebuilds' name doesn't seem to be |
21 |
> > reserved anywhere so good candidate imho. |
22 |
> > To those concerned with directory lookup speed (in order to find package |
23 |
> > by name) - generated package index file provided in ${PORTDIR} |
24 |
> |
25 |
> Alternatively, just use first letter subdivisions. Perhaps grouping them |
26 |
> as ac, df, etc, or whatever granularity seems appropriate, if desired. |
27 |
> That's a common method of eliminating large-dir issues with otherwise |
28 |
> flat listings. |
29 |
|
30 |
Using directory structure as a way to enhance performance is sign of bad |
31 |
design. Simple |
32 |
find /usr/portage/ebuilds -type d -maxdepth 1 | sort > ebuilds.index should be |
33 |
sufficient. One can even extract tags in that file and list them after package |
34 |
name for faster searching. |
35 |
|
36 |
> > - extend their metadata.xml (no ebuild variables please) with tags in |
37 |
> > accepted format. We should provide dictionary for available tags - |
38 |
> > necessary in order to avoid randomly added system tags - tag could be |
39 |
> > extended when needed - similar policy to global USE flags for instance |
40 |
> |
41 |
> Keep in mind that there has historically been extremely high resistance |
42 |
> to "xml-ifying" anything critical to operational package management, by |
43 |
> certain highly respected and politically influential gentoo devs. |
44 |
> There's a reason metadata.xml contains only "ancillary" data, while the |
45 |
> most important operational data (depends, inherits, src_uri, etc) remains |
46 |
> as variables within the ebuilds and/or eclasses. |
47 |
|
48 |
Yes, and the reason is metadata.xml can contain only version invariant data |
49 |
and should not contain anything that's required for ebuild.sh. So inherits, |
50 |
src_uris, dependencies - cannot be placed there. Assuming package names are |
51 |
unique identifiers, tags are not necessary to be available for ebuild.sh so |
52 |
metadata.xml is the best place. |
53 |
|
54 |
> I never tracked who was so stridently opposed and it may well be that |
55 |
> they've retired now, but there's some people who simply don't consider xml |
56 |
> a sufficiently robust solution in terms of parsing dependencies AND easy |
57 |
> error-free human parsability. |
58 |
[...] |
59 |
|
60 |
Let's not diverge this purely technical topic to "who thought what on what |
61 |
based on sth" or "there are some people who don't consider xml..." and let |
62 |
them speak on technical matters if they want. |
63 |
|
64 |
> FWIW, I agree that it'd be a step backward in terms of human editability |
65 |
> ease and thus I'd find it a sad day were that to happen, but my feelings |
66 |
> aren't particularly strong on the issue. |
67 |
> |
68 |
> But if packages are indeed uniquely and canonically identified by name |
69 |
> only and tags are kept as ancillary to the core merge process as |
70 |
> metadata.xml is now, there shouldn't be a problem with it. |
71 |
|
72 |
No, tags are no supposed to be critical for package manager operations. |
73 |
Package manager needs to be aware of them in order to provide useful |
74 |
searching, but that's about it. |
75 |
|
76 |
I think we'd just need some simplest proof of concept implementation... |
77 |
|
78 |
-- |
79 |
regards |
80 |
MM |