Re: [gentoo-dev] No automatic RDEPEND=DEPEND for ebuild and eclass anymore
On Fri, Jul 08, 2005 at 03:07:42PM +0300, Dan Armak wrote:
> On Thursday 07 July 2005 02:40, Sven Wegener wrote:
> > For the ebuild part the plan is to remove the automatic RDEPEND=DEPEND
> > setting from portage.
> What's the timeline for this? Are we talking about a change in portage-cvs
> (which itself is supposed to be released when?) or in the next 2.0.x rev?
It will be included in portage, when EAPI (see the EBUILD_FORMAT thread)
gets in, to provide backward compatibility for old ebuilds. This EAPI
thing takes some time, because the first API version needs to be
designed and written down. It's generally current format with some
modifications. Stable portage won't be affected by the RDEPEND=DEPEND
removal, but you can for sure include RDEPEND="${DEPEND}" in your
ebuilds to make them safe for the future. It's currently not required
and our plan is to get the changes in when EAPI goes live. And for the
release of portage-cvs to stable, you better ask one of the real portage
developers.
In short, no run on the tree is needed now. And if we need to update all
ebuilds, it will (probably) be done with a script. 2/3 of all ebuilds
currently assume the automatic RDEPEND=DEPEND setting, i.e. they set
DEPEND, but not RDEPEND.
Sven
--
Sven Wegener
Gentoo Developer
http://www.gentoo.org/
pgpEzI8TTHb3R.pgp
Description: PGP signature
Re: [gentoo-dev] EBUILD_FORMAT support
On Wed, Jul 06, 2005 at 09:01:47PM -0400, Nathan L. Adams wrote: > EVER looks like the english word 'ever'; what does it stand for? EBUILD > VERSION? If so, how about EVERSION? Since when was variable name length > a problem? Go with whatever best describes the variable and is easy to > figure out. Yes, ebuild version. For me all that starts with E (in combination with Gentoo) is separated in my mind between E and the remaining part. Like: - ebuild == e-build - emerge == e-merge And EVER automatically was E-VER for me, never had the idea to read it as ever. Does that count as being addicted to Gentoo? Sven -- Sven Wegener Gentoo Developer http://www.gentoo.org/ pgp9UtaGwrBIx.pgp Description: PGP signature
Re: [gentoo-dev] EBUILD_FORMAT support
On Wed, Jul 06, 2005 at 08:41:43PM -0400, Mike Frysinger wrote: > On Wednesday 06 July 2005 08:20 pm, Sven Wegener wrote: > > We would like to introduce a new ebuild variable named EBUILD_FORMAT, > > seems like the name is much longer than it needs to be ... what's wrong with > say 'EVER' ? It's fine too. EBUILD_FORMAT was just the name that fell in #gentoo-portage once we discussed about it. Sven -- Sven Wegener Gentoo Developer http://www.gentoo.org/ pgpGUsSKDHtVL.pgp Description: PGP signature
Re: [gentoo-dev] src_configure
On Wed, Jul 06, 2005 at 08:14:55PM -0400, Aron Griffis wrote: > Sven Wegener wrote: [Wed Jul 06 2005, 08:04:04PM EDT] > > I'm writing this mail to bring you a thought we had over on freenode > > in the #gentoo-portage channel. We would like to split up > > src_compile. The new src_configure should just do the econf part and > > src_compile should do the emake part. This represents the general > > 3-step[1] installation in a much better way. > > This would be great in that it would be possible to do: > > ebuild blah.ebuild configure > > then change to the directory and work on it. But the other side of > the coin is that you're talking about a LOT of ebuild changes, right? Yes, but please see my EBUILD_FORMAT mail on how we'll provide backward compatibility. It boils down to set EBUILD_FORMAT to the right value and portage knows that the ebuild uses src_configure in addition to src_compile. As we need to touch ebuilds for the src_configure change we can also add the EBUILD_FORMAT variable in one go. If EBUILD_FORMAT is unset, just use old behaviour. Sven -- Sven Wegener Gentoo Developer http://www.gentoo.org/ pgpyQtAybozba.pgp Description: PGP signature
[gentoo-dev] EBUILD_FORMAT support
Hi all! We would like to introduce a new ebuild variable named EBUILD_FORMAT, that tags the ebuild with a specific ebuild API version it provides or uses. ebuilds will get an automatic dependency on a version of portage that is required for the used API to work correctly. The mapping between API and portage versions will be distributed with our portage tree. There are some major ebuild API changes being discussed. These changes need backward compatibility and the information from EBUILD_FORMAT can be used to provide backward compatiblity in an easy way. It can be used for the src_configure[1] support and it might as well be used to get backward compatibility for the RDEPEND=DEPEND[2] changes. Cheers, Sven [1] http://thread.gmane.org/gmane.linux.gentoo.devel/29510 [2] http://thread.gmane.org/gmane.linux.gentoo.devel/29509 -- Sven Wegener Gentoo Developer http://www.gentoo.org/ pgpLSXDG8RAWM.pgp Description: PGP signature
[gentoo-dev] src_configure
Hi all! I'm writing this mail to bring you a thought we had over on freenode in the #gentoo-portage channel. We would like to split up src_compile. The new src_configure should just do the econf part and src_compile should do the emake part. This represents the general 3-step[1] installation in a much better way. Regards, Sven [1] ./configure && make && make install -- Sven Wegener Gentoo Developer http://www.gentoo.org/ pgp1wcyK7Q2kr.pgp Description: PGP signature
[gentoo-dev] No automatic RDEPEND=DEPEND for ebuild and eclass anymore
Hi all! OK, subject isn't fully the truth. Portage doesn't set RDEPEND=DEPEND for eclasses. So, please check your eclasses and if they only set DEPEND and you need the RDEPEND=DEPEND thing, go ahead and add it to the eclass! For the ebuild part the plan is to remove the automatic RDEPEND=DEPEND setting from portage. I can hear you scream: - "But that's a nice feature!" - "It makes my life easier. Don't do it!" Here are the reasons for removing it: - RDEPEND is the only variable that gets this special treatment. Less confusion, if we remove the "magic" from RDEPEND. - The ebuild should clearly say what it needs and not rely on portage deciding the RDEPEND=DEPEND bit. - Developers are just setting DEPEND and leave RDEPEND alone, which results in unnecessary RDEPENDs. The removal will (hopefully) make developers pay more attention and result in cleaner dependencies. - eclasses don't have the automatic RDEPEND=DEPEND thing, the change will streamline ebuilds and eclasses to be treated equally. Cheers, Sven -- Sven Wegener Gentoo Developer http://www.gentoo.org/ pgpvSMIMrVoek.pgp Description: PGP signature
Re: [gentoo-dev] *DEPEND mismatches
On Wed, Jul 06, 2005 at 02:03:32PM -0400, Michael Cummings wrote:
> Are we forbidden from DEPEND=RDEPEND...? I only ask because 90% of the
> dev-perl portions would fall into that category - if it's an rdepend, it can
> be a depend as well (technically you can build without most of the underlying
> rdepends, but you will get warnings from perl that prereqs weren't met). And
> if so, which is preferred - globbing the list in rdepend and having
> depend=rdepend, or globbing it in depend and having rdepend=depend? Thanks :)
It doesn't matter if you first populate DEPEND and then assign it to
RDEPEND or the other way round. That's totally up to you. But it is
easier, if you have more packages being RDEPEND-only to start with
DEPEND="..." and then assign RDEPEND="${DEPEND} ..."
To explain some background. Current portage automatically sets RDEPEND
to DEPEND, if RDEPEND is not set by the ebuild. This behaviour will
change in the future. That means all ebuilds need to set DEPEND *and*
RDEPEND, even if they just do RDEPEND="${DEPEND}" after setting DEPEND.
I'll send a separate email on this issue.
I prefer to have DEPEND and RDEPEND as fine grained as possible. As I
wrote, current portage forces both DEPEND and RDEPEND to be installed
for normal merges. This is broken behaviour and will change too.
Packages being only in DEPEND will be removed when running depclean. If
you use a system just for package building, why do you want to install
all runtime-only dependencies? Why do you want buildtime-only
dependencies, when merging binary packages? Why do you want
buildtime-only dependencies for already installed packages? That are the
points why *DEPEND should be fine grained as possible. This mismatch
check is done to catch runtime-dependencies being in DEPEND but missing
in RDEPEND and the other way round.
Sven
--
SVen Wegener
Gentoo Developer
http://www.gentoo.org/
pgpsTQuY7LF0Q.pgp
Description: PGP signature
Re: [gentoo-dev] *DEPEND mismatches
On Tue, Jul 05, 2005 at 06:19:01PM -0700, Robin H. Johnson wrote: > On Wed, Jul 06, 2005 at 02:00:24AM +0200, Sven Wegener wrote: > [snip] > Could you possibly split the stuff into two files? > one for RDEPEND.only and one for DEPEND.only? http://dev.gentoo.org/~swegener/qa/depend-mismatches-DEPEND http://dev.gentoo.org/~swegener/qa/depend-mismatches-RDEPEND > I see a lot more FP for RDEPEND.only. > > Many of the RDEPEND.only are correct, as the packages are just scripts > that call other binaries to do their work. On the flipside, there are a > lot of packages that only need something to build properly (eg > sys-cluster/torque needs sys-apps/ed, and dev-libs/openssl has a build > system that needs perl). Yeah, plugins are often RDEPEND-only and binary packages have an empty DEPEND. Those are special packages. I could whitelist *-plugins/* for RDEPEND that would remove them from the list. I see about 30 packages in the list that use them, maybe a good thing to whitelist for RDEPEND. I added sys-apps/ed for sys-cluster/torque and dev-lang/perl for dev-libs/openssl to the whitelist. > I suspect that you'd end up with a massive whitelist if we tried to > catch everything. The whitelist is already quite large. I don't want to catch everything that should be whitelisted. FPs that affect a lot of packages and can easy be whitelisted either general or by the means of eclass usage are good. > For the moment however, I can offer some general items: > anything inheriting php-ext*eclass is correct with DEPEND of dev-php/php but > and RDEPEND of virtual/php. Added. Sven -- Sven Wegener Gentoo Developer http://www.gentoo.org/ pgphcU8dSAryy.pgp Description: PGP signature
Re: [gentoo-dev] *DEPEND mismatches
On Tue, Jul 05, 2005 at 08:12:31PM -0400, Mike Frysinger wrote: > you should def whitelist for DEPEND only: > app-arch/zip > app-arch/unrar > dev-util/jam > media-gfx/nvidia-cg-toolkit > games-util/loki_patch I added them to the list of packages being safe to be used in DEPEND only. Sven -- Sven Wegener Gentoo Developer http://www.gentoo.org/ pgp4Pqd482Pq6.pgp Description: PGP signature
[gentoo-dev] *DEPEND mismatches
Hi all! Short explanation for the subject: A *DEPEND mismatch is when a package is listed in DEPEND, but missing in RDEPEND and vice versa. I have a list of ebuilds at http://dev.gentoo.org/~swegener/qa/depend-mismatches that contain such mismatches. I've already whitelisted packages like automake and autoconf, that are safe to be only in DEPEND. And I also whitelisted packages like emul-linux-x86-baselibs for being RDEPEND-only. Pure meta packages like gnome-base/gnome or kde-base/kde have everything whitelisted for RDEPEND and everything blacklisted for DEPEND. Additional blacklistings include virtual/modutils for DEPEND. This check is important, because when merging binary packages portage will only install RDEPEND and when building stages (via ROOT support) DEPEND will go to / and RDEPEND will got to the specified ROOT. I want to clean *DEPEND up, so that we have sane dependencies. Currently, for normal merging, portage forces both DEPEND and RDEPEND to be installed, even after the merging is complete. This might or will change in the future and break packages that have these mismatches. I want developers to take a look at the list and see if packages they maintain are listed. I'm aware that the list is quite large and still contains a lot of false positives. I can whitelist packages for DEPEND or RDEPEND either general, based on eclass usage or for a specific package. If you are sure that your package has a safe mismatch, I can add it to the whitelist. But please one after the other, this is just an initial test. Cheers, Sven -- Sven Wegener Gentoo Developer http://www.gentoo.org/ pgphkVXD5qV5M.pgp Description: PGP signature
Re: [gentoo-dev] USE_EXPAND and IUSE
On Sun, Jun 19, 2005 at 07:48:27PM +0300, Alin Nastac wrote: > Jason Stubbs wrote: > > >So there have been many complaints about how USE_EXPANDed flags don't belong > >in IUSE. There haven't actually been any reasons given though. :P > net-dialup/pppconfig-2.3.11-r1 depends on LINGUAS, but the list of > supported languages is created in pkg_unpack, based on what tarball > contains. > > The IUSE thing would raise 2 problems: > - lower maintainability - not really a major problem > - if user wants all languages, it will be forced to select them one by > one - now if LINGUAS is empty, all available languages gets installed. We're talking about USE_EXPANDed USE flags. The LINGUAS variable will still exist and the way you use LINGUAS in net-dialup/pppconfig doesn't involve USE flags. So you don't need to add them to IUSE. We currently don't have a policy that enforces the use of the expanded linguas_* USE flags instead of directly using the LINGUAS variable. Maybe we should first decide, if it's OK to use LINGUAS directly. If not, we need to modify the packages, which is tricky for packages like pppconfig that take the list of available languages from the tarball. IMHO using the linguas_* USE flags makes better binary packages because the USE flags are handled by portage and shown on emerge -pv output. Portage will merge the binary package using the compiled USE flags and will not react on current USE settings. Same is for LINGUAS, but using the USE flags the user knows on emerge -pv with which language support the package was compiled. Sven -- Sven Wegener Gentoo Linux Developer http://www.gentoo.org/ pgp39zvYjMEer.pgp Description: PGP signature
Re: [gentoo-dev] use.force support
On Wed, Jun 15, 2005 at 12:16:18PM +0200, Thomas de Grenier de Latour wrote: > On Mon, 13 Jun 2005 16:40:48 +0200 > Sven Wegener <[EMAIL PROTECTED]> wrote: > > > We just had a short discussion over in #gentoo-portage and the > > idea of an use.force file for profiles came up. It allows us to > > force some USE flags to be turned on for a profile. It's not > > possible to disable this flag by make.conf, the environment or > > package.use. But we would not be Gentoo, if we don't leave a > > backdoor. You can disable the flag by putting -flag in /etc/ > > portage/profile/use.force if you really need to. Same goes for > > sub-profiles that need to disable this flag. > > Why a file rather than a make.default variable? I'm thinking of > something like REQUIRED_USE, which would behave just like USE and > friends (the so called "incremental" vars in portage). Its > contents could simply be added to USE after all other steps of > there respective "incrementation" (profiles, make.conf, user > env, etc.). And sure there would also be a REQUIRED_USE_EXPAND > var, similar in purpose to the existing USE_EXPAND but targeting > REQUIRED_USE, where important things like USERLAND or ELIBC could > be moved. The result is the same. I prefer to use files, because they yield better cvs diff results. Seeing someone change the REQUIRED_USE line involves looking over the complete line to find the changes. We could split the line over multiple lines to make it easier, but then we could just use a flat file. Well we're talking about a couple of flags here, but we don't know what we'll use these REQUIRE_USE for in the future > Well, i'm not saying that vars are better than files though, the > same can be achieved both ways, so it's just another option to > consider. > > (and feel free to replace, in the above, "REQUIRED" by "FORCE", > "IMPORTANT", or any other kind of "DO_NOT_TOUCH"-like prefix) I actually like the required one. Sven -- Sven Wegener Gentoo Linux Developer http://www.gentoo.org/ pgp1ZhcEth1Or.pgp Description: PGP signature
Re: [gentoo-dev] use.force support
On Tue, Jun 14, 2005 at 07:50:13PM -0700, Donnie Berkholz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Sven Wegener wrote: > > On Mon, Jun 13, 2005 at 06:56:43PM -0400, Ned Ludd wrote: > > > >>I'm in favor of this. Would you mind calling it package.autouse, > >>package.use.auto or are you set on .force? > > > > > > As Mike already wrote those names are too confusing with the automatic > > activated USE flags. We already had some suggestions in this thread, but > > none of them actually matched the purpose of the file. At least in my > > opinion. use.force matches it best, but the "force" part is a quite hard > > term. How about use.profile? Because these USE flags are activated or > > needed by the profile. > > How about use.required, since they're required by the profile? Sounds good to me. use.required sounds softer than use.force but still has this "touch me and things may break horribly" bit. -- Sven Wegener Gentoo Linux Developer http://www.gentoo.org/ pgpznBc6irivm.pgp Description: PGP signature
Re: [gentoo-dev] use.force support
On Mon, Jun 13, 2005 at 06:56:43PM -0400, Ned Ludd wrote: > I'm in favor of this. Would you mind calling it package.autouse, > package.use.auto or are you set on .force? As Mike already wrote those names are too confusing with the automatic activated USE flags. We already had some suggestions in this thread, but none of them actually matched the purpose of the file. At least in my opinion. use.force matches it best, but the "force" part is a quite hard term. How about use.profile? Because these USE flags are activated or needed by the profile. -- Sven Wegener Gentoo Linux Developer http://www.gentoo.org/ pgpWHrl8bbsox.pgp Description: PGP signature
Re: [gentoo-dev] use.force support
On Tue, Jun 14, 2005 at 01:46:22PM -0400, Alec Warner wrote: > Sven Wegener wrote: > >On Mon, Jun 13, 2005 at 05:08:09PM -0400, Alec Warner wrote: > > > >>Sven Wegener wrote: > >> > >> > >>>use.force might not be the best name, but it's what we do with it for > >>>most of our users. Being able to -flag in /etc/portage/profile/use.force > >>>is just because /etc/portage/profile gets added to the cascaded profile > >>>chain. Everything we add to portage that allows a profile to revert > >>>some behaviour added by parent profiles, can also be done with > >>>/etc/portage/profile and it's good that way. So, that we're able to > >>>-flag in use.force is just part of the way cascaded profiles work. It's > >>>not a feature that will be added just to support use.force. Primary > >>>reason for use.force is to have a way to activate flags even if USE="-*" > >>>is in make.conf or environment. > >> > >>How is this not just a consequence of USE="-*"...that is what this does; > >>turns off ALL use flags. How is use.force ( or the concept thereof ) > >>not breaking the 'easy' interpretation of USE="-*" because now things > >>aren't -*, they are -* + use.force things. > >> > >>It's one of those "if you use USE="-*" you should know the consequences > >>of it...kind of deals. > > > > > >There are some USE flags that must survive the -* thing and already do > >it. One of them being ARCH, which is always there. And the USE_EXPANDed > >ones, the current important being being userland_*, kernel_* and elibc_* > >which are needed for special dependencies and checks. They are not to be > >modified by users by using USE in make.conf or the environment. They > >depend on the chosen profile and should always be enabled. We're not > >talking about every day USE flags, but really special USE flags, like > >multilib, selinux or the USE_EXPANDed ones that *must* be turned on for > >the chosen profile. Don't think of them like every day USE flags that > >allow you to tweak your system, they are used to pass some information > >from profiles to the ebuilds in a way portage can easily handle it. > > > >Hm, use.must sounds bad once I think about it more. > > > >Sven > > > I'm probably a little behind here, since this has been used for a while, > but I guess more discussion and ideas are good. > > It seems like this is an abuse of USE flags, somewhat. I guess programs > could have support for elibc_X or elibc_Y or userland_GNU or > userland_DARWIN/BSD but why a USE flag for these? If they must be > forced, force them in the environment outside of USE flag usage. USE > flags are for turning off optional support for programs, that is their > overall purpose. There isn't a use flag for kernel version, there is a > function for that. Why is there not a function to determine > userland/arch/libc? As Diegeo already wrote in his mail, the USE_EXPANDed ELIBC and KERNEL are also available as variables, but as variables we can't use them to enable or disable optional dependencies for specific kernels or libcs. Currently only USE flags are able to do it. I just had a quick look into our handbook[1] and it mentions the following definition for an USE flag: "Such a flag is a keyword that embodies support and dependency-information for a certain concept." And for sure, elibc_uclibc or kernel_linux stand for a certain concept. Same goes for multilib and selinux you mentioned further down in your mail. And they might have special dependency information and need special treatment in packages. IMHO they match the definition of USE flags just like any other USE flag we have. Even though, as I wrote in my previous mail, they are special, because they are not to be set or unset by users. You chose to activate them by chosing your profile. With use.force we're just making sure that they are actually enabled. We can give elibc_* or kernel_* another name, but in the end, they will serve the same purpose as USE flags and will be handled by portage in the same way. > In this case I think this use.force deal will create more complexity > in the USE flag area than help. This is not what use flags are for ( > also for multilib and SELINUX ). I don't see the complexity here. We're just creating a couple of files in our profiles that force some flags to be turned on. Sven [1] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=2#doc_chap1_sect2 -- Sven Wegener Gentoo Linux Developer http://www.gentoo.org/ pgpA51AYpPfFV.pgp Description: PGP signature
Re: [gentoo-dev] use.force support
On Wed, Jun 15, 2005 at 01:34:05AM +0300, Sami N??t?nen wrote: > On Monday 13 June 2005 23:54, Sven Wegener wrote: > > On Mon, Jun 13, 2005 at 03:40:34PM -0500, Kito wrote: > > > what about just a use.env? > > > > I find that a little bit misleading. Sounds like "use this > > environment" or so. > > How about use.lock, which would lock the listed use flags from normal > usage. I already had the idea of using use. and merge it with use.mask so that we have one file to force flags on or off for a profile. That means three operators, "force enable", "force disable" and "clear settings from parent profiles" but currently the parser works with just two operator, flag and -flag. So portage would need more changes here. But after reading the file portage would (assuming the current code base) split them in two categories, masked flags and forced flags, so it's easier IMHO to just keep them in two different files. Sven -- Sven Wegener Gentoo Linux Developer http://www.gentoo.org/ pgpmr8kEyDlht.pgp Description: PGP signature
Re: [gentoo-dev] use.force support
On Mon, Jun 13, 2005 at 05:08:09PM -0400, Alec Warner wrote: > Sven Wegener wrote: > > >use.force might not be the best name, but it's what we do with it for > >most of our users. Being able to -flag in /etc/portage/profile/use.force > >is just because /etc/portage/profile gets added to the cascaded profile > >chain. Everything we add to portage that allows a profile to revert > >some behaviour added by parent profiles, can also be done with > >/etc/portage/profile and it's good that way. So, that we're able to > >-flag in use.force is just part of the way cascaded profiles work. It's > >not a feature that will be added just to support use.force. Primary > >reason for use.force is to have a way to activate flags even if USE="-*" > >is in make.conf or environment. > > How is this not just a consequence of USE="-*"...that is what this does; > turns off ALL use flags. How is use.force ( or the concept thereof ) > not breaking the 'easy' interpretation of USE="-*" because now things > aren't -*, they are -* + use.force things. > > It's one of those "if you use USE="-*" you should know the consequences > of it...kind of deals. There are some USE flags that must survive the -* thing and already do it. One of them being ARCH, which is always there. And the USE_EXPANDed ones, the current important being being userland_*, kernel_* and elibc_* which are needed for special dependencies and checks. They are not to be modified by users by using USE in make.conf or the environment. They depend on the chosen profile and should always be enabled. We're not talking about every day USE flags, but really special USE flags, like multilib, selinux or the USE_EXPANDed ones that *must* be turned on for the chosen profile. Don't think of them like every day USE flags that allow you to tweak your system, they are used to pass some information from profiles to the ebuilds in a way portage can easily handle it. Hm, use.must sounds bad once I think about it more. Sven -- Sven Wegener Gentoo Linux Developer http://www.gentoo.org/ pgpNTYARbM9HT.pgp Description: PGP signature
Re: [gentoo-dev] use.force support
On Mon, Jun 13, 2005 at 03:40:34PM -0500, Kito wrote: > what about just a use.env? I find that a little bit misleading. Sounds like "use this environment" or so. Sven -- Sven Wegener Gentoo Linux Developer http://www.gentoo.org/ pgpjQajdyL9gj.pgp Description: PGP signature
Re: [gentoo-dev] use.force support
On Mon, Jun 13, 2005 at 03:56:49PM -0400, Dan Meltzer wrote: > Seems like use.force might be a bad name. when I first read the > email, and saw use.force, the first thing that came to mind was > "gentoo forcing something?" and even after reading the email, I > wouldn't expect to be able to override something that was "forced." > I'm not sure what a better name would be, but I think there may be > one... use.force might not be the best name, but it's what we do with it for most of our users. Being able to -flag in /etc/portage/profile/use.force is just because /etc/portage/profile gets added to the cascaded profile chain. Everything we add to portage that allows a profile to revert some behaviour added by parent profiles, can also be done with /etc/portage/profile and it's good that way. So, that we're able to -flag in use.force is just part of the way cascaded profiles work. It's not a feature that will be added just to support use.force. Primary reason for use.force is to have a way to activate flags even if USE="-*" is in make.conf or environment. > also, wouldn't the override be in use.unforce? >_< No, looking at package.mask in profiles for example, package.unmask is a level that comes after package.mask. First we mask packages and then we check if the user want some of them to be unmasked. The actual removing of a mask can be done with -mask'ing the exact mask in package.mask. That's rarely used, but that's the way cascading profile work in portage. May the force be with you, Sven -- Sven Wegener Gentoo Linux Developer http://www.gentoo.org/ pgpigbISibGmy.pgp Description: PGP signature
Re: [gentoo-dev] use.force support
On Mon, Jun 13, 2005 at 06:47:30PM +0200, Harald van D??k wrote: > Just a thought, but how about making use.mask lock flags instead of > forcing them off? Meaning, if use.mask contains ncurses, and > make.defaults contains USE="ncurses", this would have the same effect as > what ncurses in use.force would do. IMO, this would keep things a bit > simpler. But again, just a thought; I don't know if it'd cause any > problems for portage. I like to have them separate. USE and use.mask are incremental, that means we might lock (via use.mask) a flag that is not set by the profile the use.mask is in. This might result in unwanted locking. Considering we want to use.mask (as in the old meaning, forcing it to be off) ncurses in the current profile, then we also need to USE="-ncurses" in the profile to make sure the flag is off and not activated by another profile. This needs to be done for all flags that should be use.mask'ed and that are, depending on the profile, quite a lot. Means double management work. Other solution is to modify portage to evaluate every use.mask and USE on a per profile level. But that's somehow against the cascading aspect of the profiles. > Question: with use.force, what happens if a flag is both masked and > forced? Does it get turned on, get turned off, or get portage to > complain and abort? Good question. I would prefer to turn the flag off and make portage print a message. Sven -- Sven Wegener Gentoo Linux Developer http://www.gentoo.org/ pgpqbNNX8aW3a.pgp Description: PGP signature
[gentoo-dev] use.force support
Hi all! We just had a short discussion over in #gentoo-portage and the idea of an use.force file for profiles came up. It allows us to force some USE flags to be turned on for a profile. It's not possible to disable this flag by make.conf, the environment or package.use. But we would not be Gentoo, if we don't leave a backdoor. You can disable the flag by putting -flag in /etc/portage/profile/use.force if you really need to. Same goes for sub-profiles that need to disable this flag. This use.force support might be used as an replacement for some USE_EXPANDs like ELIBC and KERNEL because they are prone to break if the USE_EXPANDed variable is also set in the environment. Like this: [EMAIL PROTECTED] ~ $ KERNEL="foo" emerge --info | grep ^USE= USE="x86 ... userland_GNU kernel_foo elibc_glibc" I gues use.force has some other places where it is useful. Like the default-darwin profiles which use ARCH="ppc" and USE="ppc-macos" but the ppc-macos flag can be removed by using USE="-ppc-macos" in the environment. Or selinux profiles, to force the selinux flag to be turned on. Comments? Cheers, Sven -- Sven Wegener Gentoo Linux Developer http://www.gentoo.org/ pgp7afRWjUnTm.pgp Description: PGP signature
