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

[Thomas de Grenier de Latour]

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.

> 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.

> 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.
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.
 - the extended syntax would be for sets of unrelated packages,
and it's more for things like package.env that it would make sense.

> > 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. A very simple example of such a set, that
one may want to define as the packages for which a tbz2 should be
kept, is the following:
   "All system packages, but the ones named something-bin
    and the ones from the sys-kernel category".
With the "<rule> [<rule> ...]  <envfile>" syntax, you can write it
as follow:
   system !sys-kernel !*/*-bin   buildpkg.env
(where buildpkg.env is a file with FEATURES="buildpkg" sure)

Whereas if you are tied to an "<atom>  <envfile> [<envfile> ...]"
syntax, the best you can do is:
  system       buildpkg.env
  sys-kernel   nobuildpkg.env
  */*-bin      nobuildpkg.env
(where nobuildpkg.env is a file with FEATURES="-buildpkg")
It's getting a bit less intuitive imo. It's even worst if you
consider that: 
 - this "nobuildpkg.env" hack was only possible thanks to the
assumption that all matching lines are taken into account, in the
order they are in the file. If you can't even assume that, then the
best you can do is basically to list every single package you want
to match ie., write a file with hundreds of lines that you will
have to maintain up to date.
 - the "nobuildpkg.env" was easy to write because this example was
about turning on/off a single flag. But if it was about dropping
all USE flags on some packages ("-*") for instance, then the
cancellation file (what was "nobuildpkg.env" above) would have to
reintroduce all the USE from make.conf, which is ugly duplication.


> 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). Or
they would have to be declared somewhere by ebuild writers, and
what is declared would be added to the whitelist. If that is doable,
then yes, it sounds like the best approach. Btw, iirc, the idea of 
declaring this vars somewhere (in the ebuilds i guess) has already
been in the air for other reasons (env-filtering was one, and
showing them to users was another). Well, sounds like this
whitelist could be a third reason to go toward that change...

> 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?


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?

-- 
TGL.
-- 
gentoo-portage-dev@g.o mailing list