Re: [gentoo-dev] Dirt: To shove under the rug or not shove under the rug? (aka another round of USE_EXPAND)

[Jason Stubbs]

Before you reply to this.. Can you enlighten me on what the solution to the 
problem is that you are heading toward? I'm having trouble seeing what your 
real point is.

On Tuesday 27 September 2005 19:41, Diego 'Flameeyes' Pettenò wrote:
> On Tuesday 27 September 2005 12:12, Jason Stubbs wrote:
> > Which leads me to the one thing I didn't say but feel strongest about..
> > What is the real point of USE_EXPAND? What can/does it do that USE flags
> > do not?
>
> They are forced by the profile, as we don't want users to go away WITHOUT
> them when they are needed. That's the main part of it.

I wasn't referring specifically to the recent profile additions, but to 
USE_EXPAND in general. However, this is a mis-usage of USE_EXPAND. At least, 
USE_EXPAND was not designed for this purpose.

$ USE="-*" emerge info | grep USE
USE="amd64 userland_GNU kernel_linux elibc_glibc"
$ USE="-*" KERNEL="" ELIBC="" emerge info | grep USE
USE="amd64 userland_GNU"

ARCH and USERLAND are the only ones this can't be done for as portage is 
hardcoded to set them. Thus, they are the only ones you can be guaranteed of.

> Then there's the fact that I can test for a generic BSD libc using [[
> ${ELIBC} == *BSD ]], too.

This would fail in the above case as well. It is not very good for ebuilds to 
test for the values of arbitrary variables. If some information needs to be 
passed to ebuilds, there needs to be an explicit contract with portage.

> > Similar to "build" and "bootstrap"? Note, these aren't hidden either but
> > if the ELIBC and friends should be hidden those should be hidden too.
>
> But they have sort of meaning to users, for example with newuse, and does
> not screw your system around, or at least not completely (one can build a
> few packages with build useflag active and still have a working system, at
> the end).
> Changing the ELIBC/KERNEL/USERLAND is like using a sparc profile on an x86
> ...

bootstrap - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!
build - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!

Saying that setting these flags probably won't do much harm to the user's 
system doesn't mean that they should be exposed.

> Also, most ebuilds does not use the above variables in a complete way, they
> usually check for a certain content (GNU userland, FBSD libc, Linux
> Kernel). Saying for example that kdelibs uses kernel_linux can make people
> think that kdelibs works ONLY for Linux kernel, while that's not true at
> all. They are special features or workarounds that does not concern users
> at all.

So what are you really saying? Just that some USE_EXPAND usages shouldn't be 
exposed to users? That some usages should not be overridable by users? 
Neither USE_EXPAND or regular USE flags offer either of these features at the 
moment, other than all USE_EXPAND variables being non-exposed.

> > And we're back to USE flags again... ;)
>
> As they are the only way to change the dependencies, yeah, always USE is
> what we need. For the most of the uses, variables are fine, but for
> dependency we use them use-expanded.

Variables are _not_ fine. I would think it should be clear to everybody by now 
that ebuilds can not pick random things from the computer they are installing 
on to define how they will build.

# LINGUAS="" emerge kde-i18n | grep '*'
* You must define a LINGUAS environment variable that contains a list
* of the language codes for which languages you would like to install.
* Look at the LANGS variable inside the ebuild to see the list of
* available languages.
* e.g.: LINGUAS="sv de pt"

"Look at the LANGS variable inside the ebuild"!?
This is what this thread is about.

--
Jason Stubbs

-- 
gentoo-dev@g.o mailing list