Hi, Following the today discution on -dev ml about "Dynamic config files for portage", I've understood that ebuild-specific variables like "ALSA_CARDS" or "VIDEO_CARDS" can be defined in "/etc/make.conf". That's a good news, I've always wonder what was a clean way to define this variables once for all. (That said, it doesn't implies the need for splitting the file imho...). I suggest to make this more explicit in "make.conf", adding something like this: -------------------------------------------------------------------------------- # A few ebuilds use, instead of USE flags, specific variables for their # configuration, for instance media-sound/alsa-driver which uses ALSA_CARDS. # See "/usr/portage/profiles/ebuilds-var.desc" for an exhaustive list. # You can define this variables here: # ALSA_CARDS='emu10k1 intel8x0' -------------------------------------------------------------------------------- Where "/usr/portage/profiles/ebuilds-var.desc" would be a list of ebuilds, variables name and descriptions (and possible values). Something like this: -------------------------------------------------------------------------------- * media-sound/alsa-driver: ALSA_CARDS: By default, drivers for all supported cards will be compiled. If you want to only compile for specific card(s), set ALSA_CARDS to a space-separated list of drivers that you want to build. * x11-base/xfree-drm: VIDEO_CARDS: used to indicate which card(s) a user wishes to build support for. Possible values: 3dfx gamma i810 i830 matrox rage128 radeon sis [...] -------------------------------------------------------------------------------- I don't know if there are many such ebuilds, but at least for that reason, I really think some documentation is needed somewhere out of the ebuilds. This is the only solution I've found to unhide this without modifying portage code. Thanks, (and sorry if this should have gone to Documentation instead of Portage, I was not really sure.) TGL. Reproducible: Always Steps to Reproduce:
imo this would lead to incredible bloat
> imo this would lead to incredible bloat I don't know: * If there are only a few such ebuild-specific variables in use (lets say less than 10), and a typical user only need to specify 3 or 4 of them, then I don't call it a bloat. I don't want to document them in make.conf (that would be a bloat), but in a separate file. And even if you don't want to talk about it in make.conf, I think this documentation file is really needed. * If there are more than that, then the situation is worst than what I've thought, and need to be adressed at portage level. A possible approach would be: - declare them in ebuilds: | CONFIG_VARS="ALSA_CARDS" - display what is declared on "emerge -p -v": | Calculating dependencies ...done! | [ebuild R ] media-sound/alsa-driver-0.9.4-r1 +oss [vars: ALSA_CARDS] - document them somewhere, for instance in ebuild's metadata.xml: |<variables> | <var name="ALSA_CARDS"> | <description> By default, drivers for all supported cards will be compiled. | If you want to only compile for specific card(s), set ALSA_CARDS to a | space-separated list of drivers that you want to build. | </description> | <values> ad1816a ad1848 als100 azt2320 cmi8330 cmipci cs4231 cs4232 cs4236 | cs46xx dt019x emu10k1 ens1370 ens1371 es1688 es18xx es1938 es1968 es968 | fm801 gusclassic gusextreme gusmax ice1712 intel8x0 interwave interwave | mtpav opl3sa2 opti92x opti92x opti93x:ti pdplus rme96 rme9652 sb16 sb8 | sbawe serial sgalaxy sonicvibes trident via686a wavefront ymfpci | </values> | </var> |<variables> - I guess there will be a small script at some point to display ebuild's metadata, and it will be easy to add variables description printing to it: | # metadata --var-desc alsa-driver | media-sound/alsa-driver: | * ALSA_CARDS: By default, drivers for all supported cards... | Possible values: ad1816a ad1848 als100... (or it could be added to the "emerge -s" output, I don't care) - users would be free to define this vars in make.conf, or in environment, or on command line when needed. Since this variables would be declared, meaning known by emerge, they would also be good candidate to be sticky if "sticky variables" support comes at some point. My point is really that this variables are just as important as USE flags. If they are not USE flag's, it's only to avoid the USE flags list bloat. But hiding them is a bad thing.
we have local USE flags to avoid global bloat ... technically they are currently hidden ;) i wasnt knocking the idea of having *somewhere* to put it, just not in make.conf maybe this could work off of the /etc/make.conf.d/ idea for dynamic config files
Created attachment 18387 [details, diff] ivars_display--2.0.49-r7.patch Here is a small patch that implements the portage part of what I've described in comment #2. With this, you can add a new optionnal field to ebuilds, IVARS, to declare ebuild-specific variables. Such declared variables names will be displayed by "emerge -pv". I've added IVARS="ALSA_CARDS" to media-sound/alsa-driver ebuild, and IVARS="LIRC_OPTS" to app-misc/lirc ebuild: $ emerge -pv alsa-driver lirc [...] [ebuild N ] media-sound/alsa-driver-0.9.6 +oss [vars: ALSA_CARDS(!)] [ebuild N ] app-misc/lirc-0.6.6-r1 [vars: LIRC_OPTS(?)] "ALSA_CARDS" appears in red with a "(!)" mark because it is already set in my env (in make.conf). "LIRC_OPTS" appears in blue with a "(?)" mark because it is not set anywhere. I think this patch + a variables description file (copying comments from ebuilds should be enough in most cases, see next attachment for a possible starting point) + a few lines of doc in emerge manpage (ask me if you agree, I can write it) would be enough to give the needed visibility to this vars.
Created attachment 18388 [details] vars.desc Here s a possible starting point for the variables description file. I suggest "/usr/portage/profile" for its location (like "use.desc", etc.)
I like the idea of IVAR (although I would rename it to IUSE_EXPAND).
I've updated world a few minutes ago, and have seen at postinst of the dillo package: * This ebuild for dillo comes with different toolbar icons * If you want mozilla style icons then try * DILLO_ICONSET="mozilla" emerge dillo * * If you prefer konqueror style icons then try <big snip> Okay, then I have to reemerge it... Not a big issue since the package is fast to compile, but it would have been better to know that during the pretend phase. And it reminded me this bugreport... What is its status? The code part to support displaying special variables on verbose pretend is really trivial, I can update it for recent portage if there is any interest. And for the documentation file, it's just an annoucement to do so that devs slowly add what they have to add there, and declare their special variables in their ebuilds. The whole thing seems quite easy to solve, no? Okay, that's it, my small *bump*.
TGL: the dillo bug is different ... imo, it should be a local use flag ... IVAR is more for driver specific variable setup which makes more sense
I don't really see why limitating this to drivers. Imho, the same ideas can apply to any multiple choices package setting. What makes this settings different is that there are not yes/no questions. In the Dillo case, there was several (maybe five) choices like this, all mutually exclusive: this doesn't well fit the use flags system, and here a variable makes sense, no?
with dillo it should have been a local use flag it's not so much limiting to drivers as drivers is really the only thing that makes too much sense ... you want to say 'i have an nvidia card !' whereas with dillo you want 'USE mozilla icons !' ... it fits with local use flags for dillo whereas drivers are a global system thang
Created attachment 24150 [details, diff] 2.0.50_pre16--iuse_expand.patch Here is a patch that allows to declare this variables in ebuilds, and then display them on verbose pretend (just like in comment #4). The implementation does not use an additional auxdbkey, because this was problematic, as carpaski explained me on irc. Instead, the variables can be declared in RESTRICT flags, which is complete non-sense from a semantics point of view, but is convenient because the key is already there and nothing breaks if you add noise there. Well, I don't really like this solution neither, but i've not found anything better without a new auxdbkey. Syntax for a variable declaration is "iuse_expand_YOUR_VARIABLE_NAME". In the case of alsa-driver, adding "iuse_expand_ALSA_CARDS" to RESTRICT gives this output: [ebuild N ] media-sound/alsa-driver-1.0.1 +oss [vars: ALSA_CARDS(!)] 0 kB (with a "(!)" because it is set in my environnement, would be a "(?)" otherwise)
my 2 cents: IMO this belongs in an equivillent to /etc/portage/package.keywords i have all my local USE flags in /etc/portage/package.keywords and it works nicely (except the lack of ufed support for what i'm doing, not a big problem, can be fixed in ufed code). the same should be done for local env variables, how about /etc/portage/package.environment?
> how about /etc/portage/package.environment Imho, package.env(ironment) is a powerful but tricky idea. Take this /etc/portage/bashrc that was introduced in 2.0.51: it is great for tweaking CFLAGS on a per-package basis, because CFLAGS is an ebuild-time only variable. It also works fine for some FEATURES flag (the ebuild-time ones, like "noman" and friends for instance), but not for others which affect the python level of emerge. And it completly breaks emerge if you set USE there. The problem with ebuild-specific variables is that some are only interpreted at bash level (like LIRC_OPTS - that's the easy case), whereas other are expanded into USE flags at python level (the USE_EXPAND ones, like ALSA_CARDS or LINGUAS iirc). Imho, it would be very convenient to have a package.env file where one could specify all variable he wants (both bash level and python level), including CFLAGS, USE, FEATURES, and the ebuild-specific variables we were talking about here. But that's complicated to implement (well, for what it worths, i tried and didn't manage to do something really satisfying). And if we can't get something correct for all kind of variables, then such a file would be really missleading, and it's probably better not to have it.
I think documenting this in make.conf makes sense and is consistent with the treatment of the rest of the features available in that file. I've added this comment to my config, I dont call two lines bloat. It would have saved me consideralbe time searching forum. Nowhere had I seen _why_ this variable needed to be there nor that it related to the alsa-driver package. I realised myself whilst trying to clean up the mess of mixed up drivers I had on my system. Two lines like this would save a lot of time and increase understanding. #define drivers req when compiling alsa-driver (not kernel alsa). ALSA_CARDS="ens1371 cmipci es1938 " # not snd-ens1371 ! LINGUAS would probably merit similar treatment and probably VIDEO_CARDS. Regards
Not a scalable solution. Every time a package was added that used a new variable, make.conf.example would need to be updated.
Last few details are being worked out, but this will be done for next version. Output goes something like: [ebuild R ] sys-apps/portage-2.0.51.22-r1 -build (-selinux) LINGUAS="+en +ja" 0 kB The format follows how USE is outputted so that the choices are clearly displayed.
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Portage will now print USE_EXPAND with other use flags. Please continue discussion on what else you want to do here, if anything.
Released in 2.1_pre2.
