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. -- gentoo-dev@gentoo.org mailing list