Bruno <bonbons67 <at> internet.lu> writes: > > On Monday 10 October 2005 14:53, Chris Gianelloni wrote: > > > > Here's my question... use.local.desc is already package-specific, so why > > would we need yet *another* place to put package-specific definitions? > > Would it not be enough to have use.local.desc overlay on use.desc? If > > package foo uses global USE flag bar in a way different from the > > description in use.desc, then it should list the USE flag in > > use.local.desc with the correct description for that package. > > > The additionnal info about USE flags should not be what is this or that USE > flag used differently for, but rather what *exactly* does the use-flag > influence. What exact features of the program are enabled/disabled/changed by > the given USE flag. > Some USE flags are used to either compile against a lib that's shipped with a > package or with the system version of that lib. Would be useful to know. > > Then there are USE flags like static which are very unprecise. Do they mean > that the program is 100% stand-alone (e.g. does not link against any lib) or > does it have to do with *.a, *.la files being installed, or just reduce the > count of libs linked against... > > In addition, providing the info in the package metadata is cleaner as > information about a given package is in one place, and there is not one file > with 1k lines with many USE flags and their use for each and every package. > > The aim is to allow to know what happens without reading the ebuild AND the > configure script and makefiles of a package. > > Bruno >
I agree with the people who say that a USE flag should do the same thing no matter which package it is associated with. But it is true there are instances where a USE flag does something different. Just look at the example about the perl flag on mysql that is noted above. That tells me that maybe that flag on mysql shouldn't be the perl flag, but some other flag pertaining to what those scripts do, not what they are written in. So step one is to make it so a flag always does the same thing no matter what ebuild it is associated with. However, there is a problem that many USE flags are undocumented or difficult to find documentation on. There are lots of flags that are seriously great mysteries to me. Especially with packages like mplayer which has a zillion flags. Also, even though I might know generally what a flag does I wont know specifically how that effects this package. So what I propose is that each flag has a general description in use.desc as they do now. But for each individual ebuild there will be detailed descriptions of each flag the maintainer can put in if they want. So the one sentence summaries of what a flag does will be there, but you can easily access a multi-sentence, detailed, e-build specific description when you are lost. Let's do an example. xscreensaver, mplayer and gdm all respect the xinerama use flag. And it is fair to say that on all of these the flag adds support for xinerama to the package, so changing the use flag is unecessary. However, on mlpayer and on gdm you could be more precise and say that flag adds support for selecting which xinerama screen the program displays on. Whereas with xscreensaver the flag allows you to display multiple instances of the screensaver, one per xinerama screen, as opposed to one instance that spans the entire full screen. I think it's pretty obvious how that more specific information can be helpful to users. I actually know a few people that have xinerama but purposefully don't apply the xinerama flag to xscreensaver because they prefer a single instance of the screensaver stretched out. That sort of documentation is very useful and desperately needed in portage. -- gentoo-dev@gentoo.org mailing list
