Re: Two-level USE-flag system VAR: [gentoo-dev] USE="minimal" for kernel sources
On Thu, 22 Sep 2005 22:28:35 +0200 Tom Fredrik Blenning Klaussen <[EMAIL PROTECTED]> wrote: > Now as for the USE flag system. It has actually become so big > that it's difficult to use it effectively. I would actually > suggest that a two level system of USE flags could be employed. > Something like > wtk/gtk (Windowing Toolkit / gtk) > wtk/kde (Windowing Toolkit / kde) Sounds good on this example, but i'm not sure it would be that easy and meaningfull on the whole use.desc. I think you would end up with lot of "this flag should be in that category and not in this one" discussions (what already happen with packages). Also, i would be curious to see the output of an "emerge -pv" on some highly configurable packages (dev-lang/php comes to mind for instance), and whether it really improves readibility. > There could also be another category > experimental/minimal If the idea is just to give a "don't use this flag but if you know what you are doing" warning, then the best imho is simply to use.mask it in base profile. And people who know what they are doing can unmask it from their /etc/portage/profile/use.mask (syntax is "-flag"). Sure, it should not be named "minimal" in that case, since "minimal" is not something you want to mask, but rather "mini-kernel-src" or anything else that sounds like a specific flag. -- TGL. -- gentoo-dev@gentoo.org mailing list
Re: Two-level USE-flag system VAR: [gentoo-dev] USE="minimal" for kernel sources
On Friday 23 September 2005 05:28, Tom Fredrik Blenning Klaussen wrote: > Now as for the USE flag system. It has actually become so big that it's > difficult to use it effectively. I would actually suggest that a two > level system of USE flags could be employed. Something like > wtk/gtk (Windowing Toolkit / gtk) > wtk/kde (Windowing Toolkit / kde) This is just arbitrary grouping as far as USE flags themselves go. Rather than changing the name of the flags, why not just split the flags that are in use.desc into categories separated by comments? # some category use ... use ... ... # Windowing Toolkits gtk ... kde ... # some other category ... -- Jason Stubbs pgp4774wSx4uX.pgp Description: PGP signature
Re: Two-level USE-flag system VAR: [gentoo-dev] USE="minimal" for kernel sources
Tom Fredrik Blenning Klaussen wrote: > The average gentoo users are not stupid. Many people would not agree with that statement ;) come so far as to adjust something beyond the most basic USE flags at all, you're probably advanced enough to deciphre such a message. (It would be nice to have some knowledge of who the average gentoo user is though.) Now as for the USE flag system. It has actually become so big that it's difficult to use it effectively. There is a USE flag group GLEP that is being implemented...sometime ;) I don't think masking USE flags has come up...*pokes portage people* Also might want to submit the ebuild to breakmygentoo or some other overlay. I'll consider it, but as mentioned above it's really a change to an eclass. You can put eclasses in the overlay as well IIRC. -Alec Warner (antarus) -- gentoo-dev@gentoo.org mailing list
Two-level USE-flag system VAR: [gentoo-dev] USE="minimal" for kernel sources
On Wed, 2005-09-21 at 18:07 -0400, Alec Warner wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Tom Fredrik Blenning Klaussen wrote: > > On Thu, 2005-09-08 at 20:01 +0100, John Mylchreest wrote: > > > >>For the record, there is a bug open for this. (#64009) > >>Personally, I'm not keen on the idea. > >>the only way which we can do this is by detecting which arch we are > >>installing the sources, for, which immediately means many installs of > >>USE=minimal are not the same. > > > > > > I'm the reporter of the above mentioned bug (which for the record > > was /only 1 year old/ September 14. I love the response time :-) ) > > I was just made aware of this discussion, so sorry about the late > > response. > > > > I really can't see the problem with several installs being dissimilar. > > > > > >>There are plenty of other reasons I can go into, but if anyone feels > >>strongly to push this change, then feel free to reply with justification > >>as to why. Technical info to back it up as well please :) > > > > > > The only real difficulty I can see is that the kernel-devs sometimes > > pull includes from other arcs. This will cause compile errors, and under > > no circumstances any runtime problems. If the use flag also comes with a > > warning that use is on your own peril, and support is not given. Too bad > > for the people ignoring the warning. > I could see some sort of pmasked ebuild that did this. Other than that > though, I wouldn't want users to be able to touch it. It's well known > that pmasked stuff isn't supported. One can't add a use flag to an > ebuild and then turn around and say oh that use flag isn't supported. > If it's not supported it shouldn't be there. Actually a method for masking USE flags could be a good idea. Now, as said earlier the natural way to do this is in the kernel-2.eclass. So I don't see how one could pmask that. Why are you afraid of users coming near this. I don't expect this to break anything at all, but even if the errors generated are straight forward. The average gentoo users are not stupid. In fact if you have come so far as to adjust something beyond the most basic USE flags at all, you're probably advanced enough to deciphre such a message. (It would be nice to have some knowledge of who the average gentoo user is though.) Now as for the USE flag system. It has actually become so big that it's difficult to use it effectively. I would actually suggest that a two level system of USE flags could be employed. Something like wtk/gtk (Windowing Toolkit / gtk) wtk/kde (Windowing Toolkit / kde) There could also be another category experimental/minimal Using a flag from experimental would add a warning to the pacakge that uses it, and an implicit understanding that tweaking of the experimental use flags is strongly discouraged. > Also might want to submit the ebuild to breakmygentoo or some other > overlay. I'll consider it, but as mentioned above it's really a change to an eclass. Sincerely -- Tom Fredrik Klaussen -- gentoo-dev@gentoo.org mailing list
