Le Sun, 12 Feb 2006 21:39:22 -0600,
R Hill <[EMAIL PROTECTED]> a écrit :
> TGL did some work on this under bug #84884, though his changes are
> more invasive than what i had in mind. I don't see the need for
> portage to dig through use.*desc when euse already works and equery
> can pretty easily be made to.
If this "special" USE descriptions (the one in use.local.desc when the
flag is also global) are allowed, then it's in "emerge -pv" output
that displaying them is the most useful. Nobody wants to manually call
euses for each package he's about to emerge/update just in case one of
the well known flags they use has a special description. That's
something that should simply come to his attention when it's the case,
it's much easier this way.
IIRC, the behavior of my patch was that when the "--use-desc-special"
option was used, and some packages/flags in the list had special
descriptions, the relevant informations were displayed at the end of
the usual output:
% emerge -puvD --use-desc-special world
...
[ebuild U ] net-ftp/pure-ftpd-1.0.20-r2 -caps -ldap mysql pam
-postgres ssl -vchroot
[ebuild U ] ...
...
These USE flags have a package-specific description:
pure-ftpd:mysql - Allow storing accounts infos in a MySQL DB
...
Note that this patch doesn't makes portage diging through use.*desc when
this option is not used.
As for the two other patches (repoman and equery), it was just some code
cleanup (remove their own duplicate implementation of use*.desc parsers,
to replace it with some shared code).
> Anyways I just like anything that makes use.desc more useful than
>
> foo - adds support for foo
In many cases, you just can't give a better description for a global
flag, because it has two much different purposes depending on the
context (the package using it).
Take the "mysql" flag, i think it's a typical example of global flag
with different meanings: many users will enable it thinking of the PHP
bindings, whereas they don't care about using a MySQL DB to store
their FTP accounts or their music collection metadatas.
Or even take some less widely used flags, like "sqlite3"; on just six
packages using it, it can be:
- add sqlite support (which happens to be v3 only)
- add support for sqlite3 (may be in addition to the v2 controlled by
the "sqlite" flag)
- use sqlite3 for backend (but v2 has priority if "sqlite" is enabled)
- use sqlite3 for backend (and die if "sqlite" is enabled too)
Again, the global description ("Adds support for sqlite3") is vague
enough to seem ~correct in all cases, but actually gives no clue about
what turning on the flag means.
--
TGL.
--
[email protected] mailing list
