Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On 8/9/06, Brian Harring [EMAIL PROTECTED] wrote: General problem with use deps; *could* still implement it via seperating out use specific restrictions and generating the second logic statement above, but that's bit magic imo. Is it really magic? Admittedly I know exactly nothing about portage internals, but it seems to me that use-specific restrictions and version-specific restrictions are two completely separate concepts, and that you have to deal with them separately, regardless of whether you put the directives all in the same file or not. I see the normal case for gcc being something like: sys-devel/gcc[-cxx] =sys-devel/gcc-5.0 The above is very clear and obvious to me...all versions of gcc should be built with USE=cxx, and you should not try = version 5.0. If you tried to combine those two concepts into a single directive, you would end up with: =sys-devel/gcc-5.0[-cxx] and I can think of at least 3 useful and logical interpretations of that single statement. This is quite different than the same token in an [R]DEPEND, where only one sane interpretation exists. So in fact I think that in the context of masking/unmasking packages, you must deal with the version and use flag masking separately. You should not even allow the combined syntax form, since it is so ambiguous. And if you do that, then the unmasking of use-specific or version-specific masks becomes quite obvious. Placing sys-devel/gcc[-cxx] in package.unmask has no effect on the _versions_ of gcc that are masked, as it isn't a version-specific directive. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Tue, Aug 08, 2006 at 09:23:34PM +0200, Thomas de Grenier de Latour wrote: On Tue, 8 Aug 2006 00:22:50 -0700, Brian Harring [EMAIL PROTECTED] wrote: forcing cxx on via package.mask for gcc sys-devel/gcc[-cxx] If i want to build a cxx-free system, am i supposed to add sys-devel/gcc[-cxx] to its package.unmask? If so, what will prevent Portage upgrading to some package.masked 4.2_alpha version? After all, that's what a depatom interpretation would imply. Or am i supposed to carefully unmask =sys-devel/gcc-4.1*[-cxx] only, and pray for not overlooking the 4.2 upgrade when it comes (since it would bring cxx back in), and that there won't ever be a gcc-4.1.99-r42 dev's playground? Sarcasm aside, day or so I've sat and wondered about this one I don't have a good answer. For others who missed it, masks are collapsed into one statement, unmasks are collapsed into another, visibility is determined via if (!MASKED || UNMASKED) essentially. Sliding per package use masking into a seperate file sidesteps the issue via allowing for easier implementation- if (!USE_MASKED || USE_UNMASKED) (!MASKED || UNMASKED) That said, it still is an issue when use-deps hit- there isn't anything blocking a use dep being slid into the masks, requiring version ranges to be used to nuke it sanely via unmask. General problem with use deps; *could* still implement it via seperating out use specific restrictions and generating the second logic statement above, but that's bit magic imo. Perhaps an alt op? Or am i supposed to put -sys-devel/gcc[-cxx] in some profile overriding file? But then, when the tree mask is changed to sys-devel/gcc[-cxx,-fortran], my diff rule will suddenly be lost (this method of text lines overriding is okay in the context of official profiles, where coherent changesets can be done at once, but in user's config files, it's hell to maintain). Affect would be cumulative in that case, you'd wind up with a masking of sys-devel/gcc[-fortran] In short, i hope that either i have missed something about your proposal, No, per the norm you spotted something annoying overlooked by everyone else who commented. :/ Suggestions welcome- it can be sidestepped via seperate file, down the line when use-deps are available, the potential will still be waiting. Definitely grounds to force package.* instead of reusing unmask/mask, but I'd still like to get some form of solution for the general issue here- it's not going to go away unfortunately. ~harring pgpwfDifkbvRU.pgp Description: PGP signature
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Mon, 7 Aug 2006 21:41:39 -0700 Brian Harring [EMAIL PROTECTED] wrote: | The use.force feature is complementary to use.mask. It's exactly | the same concept, but inverted. | | And both files _should_ be implemented via use deps. Huh? How? -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Mon, 07 Aug 2006 21:39:46 -0700 Peter Gordon [EMAIL PROTECTED] wrote: | Zac Medico wrote: | The difference with use.force is that it prevents flags, that are | deemed extremely important, from being accidentally disabled by the | user. | | If they were so extremely important then they would not be optional, | and hence not even be USE flags at all, no? Or am I missing something? You're missing something. Vim used to have an ncurses USE flag, that would switch it between using ncurses and termcap-compat. On some archs, only ncurses was available, so some way was needed to force the use flag. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Tue, Aug 08, 2006 at 07:23:31AM +0100, Ciaran McCreesh wrote:
On Mon, 7 Aug 2006 21:41:39 -0700 Brian Harring [EMAIL PROTECTED]
wrote:
| The use.force feature is complementary to use.mask. It's exactly
| the same concept, but inverted.
|
| And both files _should_ be implemented via use deps.
Huh? How?
forcing cxx on via package.mask for gcc
sys-devel/gcc[-cxx]
forcing it off
sys-devel/gcc[cxx]
Pretty simple.
*Full* implementation of use deps requires ability to flip on use
flags as needed (whether to break soft cycles, or just implemented
such that use deps force what they need), and requires *tracking* of
the history of the toggling so that a
DEPEND=sys-devel/gcc[cxx] sys-devel/gcc[-cxx]
results in unsolvable; granted, it's a contrived example, but in a
large graph it *will* occur.
Getting it right is hard, but it's a requirement for any
implementation that intends a nonsucky resolver- 'soft' (breakable)
cycles exist already (unixodbc and qt is the classic example), the
number of soft cycles will grow once use deps are available.
So... to be able to handle use deps fully, you have to track the
flipping of it; to discern if a pkg is even usable, you have to pass
it through the mask/unmask, which can do the 'imprinting' up front.
Using package.{un,}mask for use.force/package.use.mask doesn't
actually require *fully* supporting use deps though; portage already
supports it in a limited fashion via package.use and the
package.use.mask patch zac stuffed in the other day.
Pretty much all it requires is just mangling his patches slightly so
if it's a use atom, it gets shifted out into the new dicts he's trying
to add to config.
Goes without saying there is a delay for support on this for (yet
another) mangling of portage profile support to protect itself.
~harring
pgpAIxIUhiXdo.pgp
Description: PGP signature
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Tue, 8 Aug 2006 00:22:50 -0700 Brian Harring [EMAIL PROTECTED] wrote: | On Tue, Aug 08, 2006 at 07:23:31AM +0100, Ciaran McCreesh wrote: | On Mon, 7 Aug 2006 21:41:39 -0700 Brian Harring [EMAIL PROTECTED] | wrote: | | The use.force feature is complementary to use.mask. It's | | exactly the same concept, but inverted. | | | | And both files _should_ be implemented via use deps. | | Huh? How? | | forcing cxx on via package.mask for gcc | sys-devel/gcc[-cxx] | | forcing it off | sys-devel/gcc[cxx] Mmm. See, that'll lead to error messages if the user sets USE=cxx and then tries to install gcc. With the .mask/.force, it's handled automatically and indicated visibly by use flags being (parened). | *Full* implementation of use deps requires ability to flip on use | flags as needed I implemented this a while back for Paludis and then chucked it. It doesn't turn out nicely, mostly because of flags like build and bootstrap. You'd end up with dumb cases like patch being built with USE=build then USE=-build, and all kinds of hairy USE flags being turned on. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Hi Zac,
On 8/8/06, Zac Medico [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I've written a patch [1] that implements support for use.force and package.use.force as originally
described by Sven Wegener [2] over a year ago. Basically, this feature is the exact opposite of
use.mask and package.use.mask. It forces USE flags to be enabled. The only way to disable these
forced flags is to mask them via use.mask/package.use.mask or to unforce them in the
profile stack. Users can unforce them via /etc/portage/profile/{use.force,package.use.force} in
the usual -flag way.
Looks useful for arch teams. Doesn't seem very interesting for
package maintainers.
Any chance of per-package USE defaults support? That's much more useful to me.
Best regards,
Stu
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Tue, Aug 08, 2006 at 08:33:51AM +0100, Ciaran McCreesh wrote: On Tue, 8 Aug 2006 00:22:50 -0700 Brian Harring [EMAIL PROTECTED] wrote: | On Tue, Aug 08, 2006 at 07:23:31AM +0100, Ciaran McCreesh wrote: | On Mon, 7 Aug 2006 21:41:39 -0700 Brian Harring [EMAIL PROTECTED] | wrote: | | The use.force feature is complementary to use.mask. It's | | exactly the same concept, but inverted. | | | | And both files _should_ be implemented via use deps. | | Huh? How? | | forcing cxx on via package.mask for gcc | sys-devel/gcc[-cxx] | | forcing it off | sys-devel/gcc[cxx] Mmm. See, that'll lead to error messages if the user sets USE=cxx and then tries to install gcc. With the .mask/.force, it's handled automatically and indicated visibly by use flags being (parened). The error msg would be blah is masked, with an explanation of why. Pretty standard fair, portage already does the same now for non use dep maskings. As is, the package.use.mask patch that got shoved in gives _no_ indication that it's forcing a flag off for a pkg- leaves the user wondering wtf occured once they spot the flag is disabled. Point there is that arguing against it based on UI code is a non-arguement; either implementation (for portage at least) requires mangling portage's -vp code to indicate the forced disabling/enabling. | *Full* implementation of use deps requires ability to flip on use | flags as needed I implemented this a while back for Paludis and then chucked it. It doesn't turn out nicely, mostly because of flags like build and bootstrap. You'd end up with dumb cases like patch being built with USE=build then USE=-build, and all kinds of hairy USE flags being turned on. Alternative is not being able to resolve unixodbc/qt and sizable chunks of bootstrap'ing without resorting to telling the resolver to ignore cycles. This is part of why use deps aren't implemented in portage now; doing it *fully* requires a lot of bitchy internal tracking. You can ignore it, but resolution capabilities pay the cost. ~harring pgpEjhkORpaHF.pgp Description: PGP signature
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Peter Gordon wrote: Zac Medico wrote: The difference with use.force is that it prevents flags, that are deemed extremely important, from being accidentally disabled by the user. If they were so extremely important then they would not be optional, and hence not even be USE flags at all, no? Or am I missing something? Yes. Some flags are extremely important to certain users (read: profiles) but not to others. In some cases the USE flag are so extremely important because they are more or less what makes the whole profile. Think of 'selinux' or 'multilib'. http://article.gmane.org/gmane.linux.gentoo.portage.devel/2316 -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Pardon the spam, but correcting a misstatement on my part- On Mon, Aug 07, 2006 at 09:41:39PM -0700, Brian Harring wrote: I know of selinux, and multilib- all that are effectively features, and exist in the use conditional namespace because they unfortunately straddle both (same issue with FEATURES=test). So... two flags I can think of, and it requires recording the setting in multiple spots (features, use, and now use.force). How is this improving it really? It blocks people from disabling automatic pulling in of selinux policies, presumably trying to prevent them *accidentally* disabling it. If the target is those flags... this patch doesn't really cut it either. Said patch is actually atom - flags forcing, not global forcing. A chunk of the patch actually supports flat out global forcing, thus this particular critique is invalid (the package.* stuff stands still though). Would blame me just misreading the diff, but I think the real culprit is Adult Swim showing Pee Wee's playhouse for rotting the brain instead ;) ~harring pgpTKiRU9xdFm.pgp Description: PGP signature
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Harring wrote: On Tue, Aug 08, 2006 at 08:33:51AM +0100, Ciaran McCreesh wrote: On Tue, 8 Aug 2006 00:22:50 -0700 Brian Harring [EMAIL PROTECTED] wrote: | On Tue, Aug 08, 2006 at 07:23:31AM +0100, Ciaran McCreesh wrote: | On Mon, 7 Aug 2006 21:41:39 -0700 Brian Harring [EMAIL PROTECTED] | wrote: | | The use.force feature is complementary to use.mask. It's | | exactly the same concept, but inverted. | | | | And both files _should_ be implemented via use deps. | | Huh? How? | | forcing cxx on via package.mask for gcc | sys-devel/gcc[-cxx] | | forcing it off | sys-devel/gcc[cxx] Mmm. See, that'll lead to error messages if the user sets USE=cxx and then tries to install gcc. With the .mask/.force, it's handled automatically and indicated visibly by use flags being (parened). The error msg would be blah is masked, with an explanation of why. Pretty standard fair, portage already does the same now for non use dep maskings. It does seem appealing to unify the package.use.mask and package.use.force functionality into a single file that acts like package.mask with use-deps support. If we do it this way, devs won't be able to start using package.use.mask until a new implementation is ready. AFAIK Paludis already has support for separate package.use.mask and package.use.force, so they'd have to change their implementation to be compatible with the new unified format. As is, the package.use.mask patch that got shoved in gives _no_ indication that it's forcing a flag off for a pkg- leaves the user wondering wtf occured once they spot the flag is disabled. Point there is that arguing against it based on UI code is a non-arguement; either implementation (for portage at least) requires mangling portage's -vp code to indicate the forced disabling/enabling. Some indication in the UI about flags being masked and/or forced would be nice, and prevent user confusion (as long as they understand the UI output). Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE2NCi/ejvha5XGaMRAvpaAKDghZnY4yI98yte0X88h6AjpPbsFgCePu6J x0WSvPuI/FO5Z41bgxdWLAQ= =NWMt -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Tue, 08 Aug 2006 10:57:55 -0700 Zac Medico [EMAIL PROTECTED]
wrote:
| It does seem appealing to unify the package.use.mask and
| package.use.force functionality into a single file that acts like
| package.mask with use-deps support. If we do it this way, devs won't
| be able to start using package.use.mask until a new implementation is
| ready. AFAIK Paludis already has support for separate
| package.use.mask and package.use.force, so they'd have to change
| their implementation to be compatible with the new unified format.
No, we already allow [use] deps in package.mask. It's just that using
this in place of {package.,}use.{mask,force} is a really really bad
idea and will massively hurt non-x86 users. Getting all masked errors
for this kind of thing instead of having the package manager handle it
is a huge step backwards.
--
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Brian Harring wrote: Question your method of bootstraping then- note that for gcc it's nocxx, not cxx. Meaning, USE=nocxx _disables_ building cxx; this is why default IUSE is requested, to kill off the 'no' (and it's seperate from my point)- c++ related failures there would be due to either Sorry, lack of thinking on my part. Was actually USE=-* minimal nocxx pam, which is significantly different and therefore not related to the use.force discussion. Sorry for wasting your bandwidth. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 7 Aug 2006, Peter Gordon wrote: Zac Medico wrote: The difference with use.force is that it prevents flags, that are deemed extremely important, from being accidentally disabled by the user. If they were so extremely important then they would not be optional, and hence not even be USE flags at all, no? Or am I missing something? This could allow for us to get rid of the nofoo use flag nomenclature that folks have been doing for functionality that is highly suggested to be on by default. Cheers, - -- Jason Wever Gentoo/Sparc Team Co-Lead -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE2Nc2dKvgdVioq28RAuwsAJ4vK8SgA1ghZmon2zRWIltyA/8OCQCcD6Dn XYD/+4B+vVEDYpz9ahGpcxM= =cP0R -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On 8/8/06, Jason Wever [EMAIL PROTECTED] wrote: This could allow for us to get rid of the nofoo use flag nomenclature that folks have been doing for functionality that is highly suggested to be on by default. Which would be fantastic IMO. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Jason Wever wrote: This could allow for us to get rid of the nofoo use flag nomenclature that folks have been doing for functionality that is highly suggested to be on by default. So would just adding it to make.defaults ... people using -* deserve what they get, if they don't pay attention. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Tue, 08 Aug 2006 15:56:24 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: | Jason Wever wrote: | This could allow for us to get rid of the nofoo use flag | nomenclature that folks have been doing for functionality that is | highly suggested to be on by default. | | So would just adding it to make.defaults ... people using -* deserve | what they get, if they don't pay attention. Uh, no it wouldn't. Part of the reason we have no* flags is to avoid dep problems. Consider: USE=!foo? ( some_unavailable_on_x86_package ) versus: USE=nofoo? ( some_unavailable_on_x86_package ) The nofoo flag can be use masked. The foo flag can't. This patch solves that problem. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Ciaran McCreesh wrote: Uh, no it wouldn't. Part of the reason we have no* flags is to avoid dep problems. Consider: USE=!foo? ( some_unavailable_on_x86_package ) versus: USE=nofoo? ( some_unavailable_on_x86_package ) The nofoo flag can be use masked. The foo flag can't. This patch solves that problem. So the best fix for this is not just retaining two ways to say the same thing but actually expanding it? (!foo vs nofoo). That feels really wrong. Maybe it needs to get fixed, but is this the right way? Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Tue, 08 Aug 2006 16:22:42 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: | So the best fix for this is not just retaining two ways to say the | same thing but actually expanding it? (!foo vs nofoo). That feels | really wrong. The Vim / ncurses example I posted earlier is perhaps a more practical illustration of the same point. The problem is, any system that doesn't allow forcing as well as masking use flags leads to ugly cases needing either !arch? or weirdly named (e.g. noncurses) USE flags. Without use forcing, we have to have a mixture of foo and nofoo flags including cases where there are both foo and nofoo for the same value of foo. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Ciaran McCreesh wrote: On Mon, 07 Aug 2006 21:39:46 -0700 Peter Gordon [EMAIL PROTECTED] wrote: | If they were so extremely important then they would not be optional, | and hence not even be USE flags at all, no? Or am I missing something? You're missing something. Vim used to have an ncurses USE flag, that would switch it between using ncurses and termcap-compat. On some archs, only ncurses was available, so some way was needed to force the use flag. That's a nice counterexample. Thanks for the explanation. :) -- Peter Gordon (codergeek42) Gentoo Forums Global Moderator GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ signature.asc Description: OpenPGP digital signature
[gentoo-dev] use.force as a complement to use.mask in profiles
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I've written a patch [1] that implements support for use.force and
package.use.force as originally described by Sven Wegener [2] over a year ago.
Basically, this feature is the exact opposite of use.mask and package.use.mask.
It forces USE flags to be enabled. The only way to disable these forced flags
is to mask them via use.mask/package.use.mask or to unforce them in the
profile stack. Users can unforce them via
/etc/portage/profile/{use.force,package.use.force} in the usual -flag way.
If use.force is abused, then it will make it difficult for users to disable
unwanted USE flags. Therefore, the only flags that should be forced are those
that should almost certainly be enabled. This is complementary to USE masking,
which should only be used to mask flags that should almost certainly be
disabled.
We've discussed this feature on the gentoo-portage-dev mailing list [3] and
people have expressed a desire to have the use.force feature. People also want
a way to enable default flags via IUSE, but that is a distinctly separate
feature. Considering that we have a proposed implementation for use.force,
shall we add support it now?
Zac
[1] http://dev.gentoo.org/~zmedico/portage/branches/2.1/patches/use.force.patch
[2] http://article.gmane.org/gmane.linux.gentoo.devel/28727
[3] http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2287
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFE19O+/ejvha5XGaMRAsf2AJ4nC+m6Jp7FBMQYp3u4O+woSzoZxQCgk0tF
FMWOljyTePUjqD535K6AeWk=
=FwyG
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Zac Medico wrote:
I've written a patch [1] that implements support for use.force and package.use.force as originally
described by Sven Wegener [2] over a year ago. Basically, this feature is the exact opposite of
use.mask and package.use.mask. It forces USE flags to be enabled. The only way to disable these
forced flags is to mask them via use.mask/package.use.mask or to unforce them in the
profile stack. Users can unforce them via /etc/portage/profile/{use.force,package.use.force} in
the usual -flag way.
If use.force is abused, then it will make it difficult for users to disable
unwanted USE flags. Therefore, the only flags that should be forced are those
that should almost certainly be enabled. This is complementary to USE masking,
which should only be used to mask flags that should almost certainly be
disabled.
We've discussed this feature on the gentoo-portage-dev mailing list [3] and
people have expressed a desire to have the use.force feature. People also want
a way to enable default flags via IUSE, but that is a distinctly separate
feature. Considering that we have a proposed implementation for use.force,
shall we add support it now?
I read the portage-dev discussion, and I'm still not seeing how this is
superior to make.defaults. If you want to be enabling local USE flags by
default, this is no less of a hack than that is -- what's truly needed
is some way to set per-package defaults.
The only valid use I can see is things like the architecture, libc, and
so forth. And it seems like there ought to be better solutions to this
than adding another hack on top of USE.
BTW your mail was really difficult to reply to, since it didn't have any
line wrapping.
Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: I read the portage-dev discussion, and I'm still not seeing how this is superior to make.defaults. The difference with use.force is that it prevents flags, that are deemed extremely important, from being accidentally disabled by the user. If you want to be enabling local USE flags by default, this is no less of a hack than that is -- what's truly needed is some way to set per-package defaults. That's distinctly separate feature that is also needed. The only valid use I can see is things like the architecture, libc, and so forth. And it seems like there ought to be better solutions to this than adding another hack on top of USE. The use.force feature is complementary to use.mask. It's exactly the same concept, but inverted. BTW your mail was really difficult to reply to, since it didn't have any line wrapping. Sorry about that. I don't like forced line wrapping but I understand that many email clients don't behave very well without it. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE2AWq/ejvha5XGaMRAkxCAKDeBiDdrPFoUxMpSbin0OAunF0ZDwCgmnB5 n84YnXuED/W01dTO4vl5nyc= =cGVg -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Zac Medico wrote: The difference with use.force is that it prevents flags, that are deemed extremely important, from being accidentally disabled by the user. If they were so extremely important then they would not be optional, and hence not even be USE flags at all, no? Or am I missing something? -- Peter Gordon (codergeek42) Gentoo Forums Global Moderator GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Mon, Aug 07, 2006 at 08:31:55PM -0700, Zac Medico wrote: Donnie Berkholz wrote: I read the portage-dev discussion, and I'm still not seeing how this is superior to make.defaults. The difference with use.force is that it prevents flags, that are deemed extremely important, from being accidentally disabled by the user. Name a few please. I know of selinux, and multilib- all that are effectively features, and exist in the use conditional namespace because they unfortunately straddle both (same issue with FEATURES=test). So... two flags I can think of, and it requires recording the setting in multiple spots (features, use, and now use.force). How is this improving it really? It blocks people from disabling automatic pulling in of selinux policies, presumably trying to prevent them *accidentally* disabling it. If the target is those flags... this patch doesn't really cut it either. Said patch is actually atom - flags forcing, not global forcing. The original request (url to sven's discussion) was actual globally forced flags, not per package- would have to specify every single consumer of selinux flag (for example) to get the same. If you want to be enabling local USE flags by default, this is no less of a hack than that is -- what's truly needed is some way to set per-package defaults. That's distinctly separate feature that is also needed. What you've implemented is just that however; the only difference is that it's forced rather then 'default' configuration state. The only valid use I can see is things like the architecture, libc, and so forth. And it seems like there ought to be better solutions to this than adding another hack on top of USE. The use.force feature is complementary to use.mask. It's exactly the same concept, but inverted. And both files _should_ be implemented via use deps. I've yet to see the exit strategy for these files when use deps comes about also; when either portage grows it, or portage gets replaced, going to basically have one file that is non use dep restrictions, and one that allows use deps. Why again are these two files being added? Use use dep syntax in package.mask, no exit strategy needed- just requires splitting the deps out from there instead of reading two seperate files. ~harring pgpXsV5wTrwg3.pgp Description: PGP signature
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
Peter Gordon wrote: Zac Medico wrote: The difference with use.force is that it prevents flags, that are deemed extremely important, from being accidentally disabled by the user. If they were so extremely important then they would not be optional, and hence not even be USE flags at all, no? Or am I missing something? Hmm... I set out to build a system recently (since 2006.0) with USE=-*, just to see if I could. After borking python a couple of times (you know how it is ;)), I was prevented from completing system by a couple of ebuilds failing on not having c++ available. One was bison, which failed on one of its examples rather than on the program itself. I can't remember what the other package was, but it was a C-only package (yacc maybe? or did it begin with a 'g'?) that failed in configure - I remember wondering where the Removing useless C++ checks message was when I needed it. Around about then I stopped having spare time, so I never filed bugs or investigated further. My point, now that I've bored you all with a long story, is that if you're careful about it, no USE flag is *truly* required, at least for a working system. Sure, some are highly recommended - but isn't that what defaults are for? :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force as a complement to use.mask in profiles
On Mon, Aug 07, 2006 at 09:57:39PM -0700, Ryan Tandy wrote: Peter Gordon wrote: Zac Medico wrote: The difference with use.force is that it prevents flags, that are deemed extremely important, from being accidentally disabled by the user. If they were so extremely important then they would not be optional, and hence not even be USE flags at all, no? Or am I missing something? Hmm... I set out to build a system recently (since 2006.0) with USE=-*, just to see if I could. After borking python a couple of times (you know how it is ;)), I was prevented from completing system by a couple of ebuilds failing on not having c++ available. Question your method of bootstraping then- note that for gcc it's nocxx, not cxx. Meaning, USE=nocxx _disables_ building cxx; this is why default IUSE is requested, to kill off the 'no' (and it's seperate from my point)- c++ related failures there would be due to either A) bootstrap script was stupid, wasn't working around portage correctly B) portage was dumber then the norm, and was screwing up dependency ordering (woot) ;) C) user intervention somehow screwd up the bootstrapping ;) My point, now that I've bored you all with a long story, is that if you're careful about it, no USE flag is *truly* required, at least for a working system. Sure, some are highly recommended - but isn't that what defaults are for? :) Better point would be that the dependencies in use aren't actually representative- if it requires c++ from gcc, it should be a use dep (something portage doesn't yet support). *Forcing* it to always have c++ on isn't much better either. ~harring pgpfRxgHmDTIy.pgp Description: PGP signature
