On Saturday 05 November 2005 05:08, Thomas de Grenier de Latour wrote: > On Sat, 5 Nov 2005 02:55:01 +0900 > > Jason Stubbs <[EMAIL PROTECTED]> 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@gentoo.org mailing list
