Re: [gentoo-portage-dev] [Bug 44796] Per package environment variables

[Jason Stubbs]

On Saturday 05 November 2005 05:08, Thomas de Grenier de Latour wrote:
> On Sat, 5 Nov 2005 02:55:01 +0900
>
> Jason Stubbs <jstubbs@g.o> wrote:
> > gnome-*/* for package.keywords is already not supported.
>
> Sure, i know, but i think it's already an unfortunate limitation
> there, and i would rather not see it again in future new config
> files.

Having some config files follow one syntax and others following another 
becomes more confusing. I don't see a problem with changing or extending
the syntax; I just think it should be done across all config files.

> > There is already a (closed) bug asking for regex atom support.
> > This is essentially what you are asking for with the BUILD_PKGS
> > patch.
>
> That, plus:
>  - the "!atom" negation thing (which is different from "-atom"
> sure), because the ability to match sets of packages induces the
> need to exclude some too, if we want to allow accurate definitions
> of packages sets.
>  - the "system" thing, because its a subset which cant be defined
> with patterns or anything like that, and is useful (at least in the
> BUILD_PKGS case).
>  - the fact that it works sure, although i agree that adding a
> special case to the package.env thing to reach that goal with that
> approach too would be easy.
>
> > The difference is that you are completely breaking away from the
> > mostly standard configuration mechanisms portage currently
> > supports.
>
> Yes. The depatoms syntax was defined for *DEPEND variables and is
> perfectly fine there, but imho, for some completly different
> purposes, it is far from being optimal. Especially in conjonction to
> this ignominous best_match_to_list() thing.

I'm not sure what ignominous means. The best_match_to_list() just checks
which atoms match against a cpv...

> > The extension to per-package configuration beyond basic atoms is
> > fine, but it needs to apply everywhere.
>
> Everywhere? No, imo some stuffs are better defined with the strict
> depatoms syntax, while others would benefit of an extended syntax.

Everywhere meaning all configuration files.

> It's a matter of what kind of packages sets you want to talk about:
>  - strict depatoms are for single or multiple versions of a
> single package, and are perfect in *DEPEND strings, masks, emerge
> command-line, etc.

I don't see why masks should be excluded. As I said in the other thread,
I always run whatever is the latest packaged KDE. Being able to specify 
kde-base/* would be much easier than the current method of specifying 
individual atoms.

> > > Since being able to list several env file on a same line doesn't
> > > sounds like a must have feature to me, i would much prefer a
> > > package.env format of that kind:
> > >   <rule> [<rule> ...]    <envfile>
> > > where <rule> would be similar to what i've defined for
> > > BUILD_PKGS (with addition of full versioned dep atoms, which is
> > > a trivial change to my code).  And if a package happens to
> > > match the rules lists of several lines, then the corresponding
> > > env files would all be sourced, in the order of the said
> > > lines.  I can try to implement that if you agree on the idea.
> >
> > I don't see the difference in the end result. I can only see a
> > difference in perspective. Perhaps you could enlighten me on this
> > point?
>
> The difference is the ability to define accurate packages sets,
> which are the result of substractions, and thus needs severals
> sub-rules to be defined.

Ok. Although with package.env, it would be equally as useful to be able to 
specify multiple envs after a rule-set. Perhaps it should be
<rule> [<rule> ...] <separator token> <envfile> [<envfile> ...]
?

> > Rather than blacklist, I'd think that whitelisting is easier.
>
> What i thought first too, but won't work for ebuild-specifics
> variables (like LIRC_OPTS and a few other ugliness of that kind).

Actually, I meant whitelisting in documentation. Perhaps blacklisting would
be easier to document. Either way, I can't see much point in removing settings 
that will have no affect if they are documented to have no affect.

> > Stuff known to portage that is okay to per-package
> > --------------------------------------------------
> > ACCEPT_KEYWORDS
> > FEATURES="buildpkg ccache distcc keeptemp keepwork noauto noclean
> > nodoc noinfo noman nostrip sandbox sfperms suidctl test userpriv
> > usersandbox"
> > USE
>
> Do you mean they already work with the patch in its current state,
> or that they could to work if some required changes are made?

Most operate only on the bash side and/or within doebuild (which should be 
getting a setcpv()'d settings object already) so should work. The rest just
require setcpv() to be called and/or relocated.

> Oh, and something i've just wondered about and i prefer to mention
> before i forget: what about USE_EXPAND variables? Are they handled
> fine with the current patch, or is the "variable -> USE flags"
> conversion done only once for all in portage?

There's a block of code near the end of config.__init__ that sets up 
USE_EXPAND. This block would need to be moved into regenerate().

--
Jason Stubbs
-- 
gentoo-portage-dev@g.o mailing list