Re: [gentoo-dev] use.force support

[Sven Wegener]

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/