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