On Friday 04 November 2005 04:30, Thomas de Grenier de Latour wrote: > On Fri, 4 Nov 2005 01:19:35 +0900 > > Jason Stubbs <[EMAIL PROTECTED]> wrote: > > package.env would be a list of "<atom> <file> [<file> ...]" > > ... > > > With a couple of small modifications to emerge to check FEATURES > > for "buildpkg" after the call to setcpv() is done rather than > > doing it once globally, this would also cover TGL's BUILD_PKGS > > addition too. > > Not if env files are only selectable by strict depatoms. I mean, > sure this syntax is perfect for *DEPEND strings, and is fine for > package.{use,mask,unmask} (although the randomness of > best_match_to_list() is rather annoying). But for package.keywords, > it is already sub-optimal imho (i run ~arch so i don't care > much, but for instance i often see people on forums who list > some whole categories there), and it would be too for the generic > package.env. For instance, people who develop gnome stuffs might > want to use the debug env for gnome-*/* packages. As for > the buildpkg FEATURES flag, it would be a real pita if i had to list > all packages matched by my current BUILD_PKGS spec (just look at > the examples i've put in my email on that topic to get the idea).
gnome-*/* for package.keywords is already not supported. There is no difference between what I/pclouds is suggesting for package.env and package.keywords. What you are really after is for extending the configuration syntax to support more than just the DEPEND atom. I was going to reply to that earlier but this patch came up in between me reading it and, umm, now. If the configuration syntax is going to be extended, it needs to be extended across the board. There is already a (closed) bug asking for regex atom support. This is essentially what you are asking for with the BUILD_PKGS patch. The difference is that you are completely breaking away from the mostly standard configuration mechanisms portage currently supports. The extension to per-package configuration beyond basic atoms is fine, but it needs to apply everywhere. If it can remain quick all the better, but the most important thing is that whatever syntax is used can be used whereever an atom can be used at the moment. > 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? > My second concern is about unsupported variables (some of the > FEATURES flags, some of the *DIR locations, etc.): i think they > should be somehow blacklisted, to avoid crazy breakages/bugreports > (btw, a quick look on the variables listed in make.conf.example > made me realize it was not that easy to write an accurate > blacklist, which tends to confirm it's really needed). Rather than blacklist, I'd think that whitelisting is easier. Anything unknown to portage (and hence only used on the bash side) will work. 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 Stuff documented but unknown to portage that will work per-package ------------------------------------------------------------------ MAKE_OPTS CFLAGS CHOST CTARGET EBEEP_IGNORE EPAUSE_IGNORE NOCOLOR Stuff known to portage but is portage configuration --------------------------------------------------- FEATURES="autoaddcvs cvs digest distlocks fixpackages getbinpkg gpg mirror notitles severe sign strict" FETCHCOMMAND GENTOO_MIRRORS PKGDIR PORT_LOGDIR PORTAGE_BINHOST PORTAGE_NICENESS PORTAGE_TMPDIR PORTDIR PORTDIR_OVERLAY RESUMECOMMAND ROOT RSYNC_EXCLUDEFROM RSYNC_RETRIES RSYNC_TIMEOUT RPMDIR SYNC USE_ORDER * Some of those FEATURES could probably be moved to the supported list Stuff unknown to portage but is only documented as it affects the default FETCH_COMMEND ------------------------------------------------------------------------- http_proxy ftp_proxy The question of facing the supported vs unsupported variables is one that we have been facing for some time. Just looking at the short list of those that are known to portage and can be supported, it's a hell of a lot of options to implement as separate configuration files. Thinking of not support per- package env in some way or another at some point down the track is pure fantasy. -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list