On Sat, 2005-01-15 at 17:44 +0000, Stuart Herbert wrote: > At the moment, USE flags are the only per-package mechanism available to > users > to indicate their choices. Maybe we need per-package FEATURES? That would > seem a more appropriate place for John's symlink support? > > > The line of thought > > is more that USE flags are getting abused for things they weren't meant > > for. I personally believe this particular one is one of them.
I feel first of all I should thank Stuart for phrasing this so well. Our current philosophy as a distribution is to give the user what they want, how they want it, without the cruft. I feel that we do this very well but this is achieved via USE flags when talking about build-time/"install-time" options. Kernel sources are not the same as many packages in the tree. Users install a common code-base which is patched in different ways. The actual user choice is then dictated by their .config options. The kernel sources themselves have no need of built-time options changed by USE flags in this way, which is how the actual policy documentation describes the use of USE. This leads me on the behavioural changes. Behavioural changes either at build-time or "install-time", cannot be differentiated. These are however, according to documentation dictated by USE. As trivial as setting up a symlink seems for many of us after the install, it is a key phase in the installation of kernel-sources/module automation. If there were to be a tool to parse the output of emerge -Du and to see something supplying virtual/linux-sources being updated, and from that install new sources modules which you commonly use on your system, the use of this flag would be very important. And after seeing bugs where people are doing this and with a minor goal of looking how kernel@ can better improve the kernel-sources/module relationship, I felt it was warranted. I would of, as I suggested earlier in the thread prefered to use a local use, but since this is in an eclass and effects some 20+ packages it is better suited global. I am not against any better alternative, but I feel environment variables or anything immediately available is as intuitive as USE. Perhaps I am wrong, and If I am I will not object to being corrected. However I would not like to see sys-kernel/* read anything from outside of portage (ie: config file) to find this behavioural setting. Hopefully this better presents my reasoning behind this additional. However, this thread alone does demonstrate the need for a more intuitive, defined, and categorised system. <insert link to GLEP> Regards, John -- Role: Gentoo Linux Kernel Lead Gentoo Linux: http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515
signature.asc
Description: This is a digitally signed message part
