This seems to be a recurring theme. It would be wonderful if there was a way to provide different USE flags for different packages. For example: I want to install net-im/gaim with perl support because I have a gaim script makes creative away messages. Now, I also want to install media-gfx/gimp which also has optional perl support, but I don't want all the stuff that gimp will need to satisfy the perl support. With the way portage is currently, I can add "- perl" in global (make.conf) USE flags and install gaim by providing USE=perl in the command-line environment. Granted, this works, however next time gaim gets a new version and I do an emerge -u world, gaim now doesn't have perl support. I'm stuck with remerging it by specifying USE on the command-line again. So, what I've cooked up is a patch to portage and a one-line patch to emerge that will allow for the following syntax in USE flags: USE="flag1 flag2 -flag3 -flag4 ( cat/pkg flag3 -flag2 )" In other words I can now have my make.conf USE flags as such: USE="-perl ( net-im/gaim perl )" So the per-package flag overrides the "global" flag. This has the added bonus of allowing versioning in the USE flags as well (e.g. package name as "net- im/gaim-0.59). The main portage patch takes care to clean up any cruft the user might cook up, but it is *NOT* foolproff. Also, please note that I didn't know *any* python a week ago. :-) I'm sure it has it's fair share of rough edges. Incidently this is what my USE flags will now be: USE="alsa dvd mozilla pic samba tiff moznoirc moznomail moznocompose ( media-gfx/gimp -perl ) ( net-misc/nut -png ) -apm -crypt -encode -gdbm -gnome -gpm -gtk -imlib -mikmod -nls -qt -slang -svga -tcpd -xmms"
Created attachment 7155 [details, diff] portage.py to allow for per-package USE flags This is the main patch to portage.py described above. This is written against portage-2.0.46-r4 but hopefully it applies ok to portage-2.0.47 as it mainly adds code. Please be aware that this is my *first* python work ever. It may case uncontrolled muscle spasms. If you have a heart condition ask someone else to make sure this code is safe first. You have been warned. :-)
Created attachment 7156 [details, diff] emerge to allow for per-package USE flags one-line change in emerge needed to make this "motha" work.
If you don't mind some criticism, I have to say I don't like this way of handling. I think it would be much more transparent for users that we save the used USE-flags in /var/db/pkg/cat/pkg/USE or similar (hey, look, we already do that :) and when Portage decides to upgrade the package, it'll check these USE-settings. This does have one great problem that I acknowledge: when a user changes his USE-variable because he now wants extra support for, let's say, "gtk", then an upgrade of the packages will not take those changes in account. Perhaps adding output to the "--pretend" that says something like: [ebuild U ] media-libs/openal-20020127 USE: "-gtk -gnome" in such a way that this would inform the user that openal will be emerged with different USE-settings than the global settings. The USE: "..." will show the differences in comparison with the global. The reason I don't like the proposed approach is that I am now comfortable with the ease of USE (just flags, nothing more) and that I am afraid that the USE-variable will become cluttered with more and more information in such a way that it will be almost impossible to "read" the variable correctly.
Don't mind critisism at all, in fact, thank you for your comments. As a quick response to the "complication of USE flags" concern, let me say that this doesn't complicate matters if you don't want it to. The USE flags continue to function as you have them now *unless* you add the extra functionality yourself. If you *do* want this, it seems like an easy thing to add which gives an option to everyone. BTW, I also like your idea of showing which USE flags affect which package at -- pretend time, but thats different functionality. :-)
Created attachment 7264 [details, diff] portage.py patch to allow per-package USE flags update to portage-2.0.46-r6
Created attachment 7265 [details, diff] emerge patch to allow per-package USE flags update to portage-2.0.46-r6
I don't think that using the knowledge in /var/db/pkg/category/package/USE is the best idea. I believe it is better that users specifically sellect the options they want per package. Whether to store this in /etc/make.conf or somewhere else is still debatable. I believe storing them in the USE variable makes this variable get too large, so A package specific file that gets included after make.conf would have my preference. This also allows other variables to be set in this configuration file. Also the work needed to make it work should be minimal
Actually, including a package-specific file after make.conf is not entirely correct because this doesn't respect the USE_ORDER variable. What if you want to just temporarily override the USE flags by setting the environment before emerge? The way this patch works, you can use these per-package settings at any place where USE flags get set (env, conf, auto, defaults).
Of course a package specific file needs to respect the USE_ORDER variable, but temporary environment flags doesn't work as that is not package but emerge session specific
How about in the file where you can pin a package to a specific version (I forget its name), you can specify USE flag overrides on the same line. That way it would be easy to go one place and see all the USE flag per-package overrides.
Do you mean package.mask? Or specific ebuild files? If so, that would require a user to modify those files every time emerge rsync is performed. If this isn't what you had in mind, my appologies. :-)
I think he means /var/cache/edb/world . I think this is a good idea. It is easy to implement and rather fool-proof
Created attachment 9218 [details, diff] update to latest portage and another feature Even though the currently posted patches apply fine (with offsets), I wanted to update them to the latest portage release (2.0.47-r8). This set also includes another small feature: show the per-package settings on the emerge --info screen (as the PKGUSE="" variable)
Created attachment 9219 [details, diff] update to latest portage and another feature the associated patch to emerge to the portage.py patch above. BTW: I don't know if PKGUSE is the best keyword to use for this functionality. It all works -- but is still very "proof- of-concept".
Created attachment 10588 [details, diff] updated and fixed portage.py patch I discovered a very bad bug (created because of my limited python knowledge). Apparently, when assigning lists (or any object, I guess) such as: myusesplit=usesplit actually assigns the reference, thus any changes to myusesplit would also affect usesplit. Because of this, once a package useflag overrides a global useflag, the globals remain changed and flow down to all subsequent checks for that particular flag. I don't know how to copy values in python instead of references so I just created a for-loop to achieve the necessary functionality. This new patch also upgrades to portage 2.0.47-r10 and handles all the --verbose printing correctly. This also contains the --info functionality so I'm going to obsolete all previously submitted patches.
Created attachment 10589 [details, diff] updated and fixed emerge patch here's the counterpart emerge patch which has been updated to portage-2.0.47-r10 and fixed to work with --verbose correctly.
Created attachment 12254 [details, diff] new portage.py patch changes: - update to portage 2.0.48 - slightly cleaner usesplit copy ( myusesplit=usesplit[:] )
Created attachment 12255 [details, diff] new emerge patch changes: - update to portage 2.0.48
Hello, Is someone looking at this patch?? I desperately need this functionality. Currently, I cat /var/db/pkg/*/USE and then USE="whateverflags" emerge whateverpackage but it is annoying, and can't be automated. Thanks, Norberto
Created attachment 13752 [details, diff] portage.py-2.0.48-r1-per_package_use_flags.patch Latest version changes: this one is vastly more resilient to syntax/whitespace errors in users' make.conf files. It is now not required to have spaces around '(' and ')'. So things like this work just fine: USE="(app-text/ghostscript -cups) (media-gfx/gimp -perl)alsa dvd ldap" This version will also spew a warning and gracefully deal with insufficient parameters to the () pair. Mismatched parens will still cause the user some grief, but not much can be done about that.
Created attachment 13753 [details, diff] emerge-2.0.48-r1-per_package_use_flags.patch same as the previous emerge patch, but this one is versioned for consistancy.
*** Bug 23925 has been marked as a duplicate of this bug. ***
a new patch is going to be added here soon by alkern (Thanks Max!!!) i really really like the idea behind the new patch, and would just like to give my 2c and say id love to see this included. :)
Created attachment 14390 [details, diff] portage.py-2.0.48-r1-per_package_use_flags.patch Ok, as John promised (thanks for your support!!!), here's the new new porage.py patch. The most notable changes are: - the new version is 67 lines instead of 160. :-) - addressing Sven's and Paul's concern about interface, moved all the functionality out of USE= in /etc/make.conf to /etc/portage/package.use. My workstation is now looks like so: valkyrie ~ $ cat /etc/portage/package.use net-mail/evolution -mozilla media-gfx/gimp -perl -gnome media-sound/xmms -gtk -gnome app-cdr/cdrdao -gnome media-video/xine-ui -gnome These settings override those specified in USE= of /etc/make.conf. However, these are set only in one place so they can't be overridden on command-line.
This latest patch is a much better implementation. I like it. I'd like to see it work with the command line changes though. Minimally printing a warning on collisions. Also, it should create a variable that can be stored in /var/db and tzb2 metadata like USE presently is. Just provided the USE flags that are modified. PUSE="-doc ssl" or something along those lines.
Created attachment 14678 [details] script to check flags This script was quickly written to check all apps currently installed on the system, and the use flags that was used to install it. if the USE flags used to install differ to those in make.conf, it will add a correct entry into /etc/portage/package.use with any flags which have changed.
Created attachment 14679 [details] try this one instead ;) (checkcurrentcustomflags)
Comment on attachment 14679 [details] try this one instead ;) (checkcurrentcustomflags) theres one thing that needs fixing here - but i cant right now. that is that itll drag any mis-matched useflags, whether or not they are valid to the ebuild. it wont cause any issues with the patch logic (afaik) except that it would save un-needed lines in package.use thanks to spyderous for pointing that out
Awesome! I'm slowly working on carpaski's suggested additional features. Hopefully I'll have a new patch soon.
Created attachment 14847 [details] re-written, much faster, much nicer, and works properly?
Created attachment 14873 [details] checkflags now does some basic logic on the overlay also.
Created attachment 15239 [details, diff] portage.py-2.0.48-r7-per_package_use_flags.patch Here's an update to fill a few of carpaski's requests. New features include: - fix a logic bug in the parsing code - creates a PUSE metadata file with any overridden flags - shows the overridden flags in different colors when doing -vp (darkred and darkblue) So it now requires a one-line patch to ebuild.sh (will attach it shortly). The only remaining problem I'm having is how to override settings on command-line. Since all the incremental dbs are put together _before_ regenerate() runs, i don't know to work this into the scheme of things properly. I'll keep trying to come with a clean integration, but if anyone has any suggestions, I'm all ears.
Created attachment 15240 [details, diff] emerge-2.0.48-r7-per_package_use_flags.patch
Created attachment 15241 [details, diff] ebuild.sh-2.0.48-r7-per_package_use_flags.patch
Created attachment 15291 [details, diff] portage.py-2.0.48-r7-per_package_use_flags.patch Ok, I put together a way of allowing flags to be overridden on command-line. Actually, the latest patch will just respect USE_ORDER. So if a user changed his/her USE_ORDER to not have 'env' take precedence over everything else, it won't allow changing flags on command-line. But that is expected behaviour.
Created attachment 15303 [details, diff] portage.py-2.0.48-r7-per_package_use_flags.patch Ok, hopefully this is the final way this will look. This allowes for lines to be commented out with '#', and also permits versions in package specification. So you can do something like the following (stolen from John's suggestion): <net-im/gaim-0.62 gnome >=net-im/gaim-0.63 -gnome Next up: port it to 49_pre17 version.
Created attachment 15304 [details, diff] emerge-2.0.48-r7-per_package_use_flags.patch
The three patches apply cleanly (with offsets) to the .49_pre17. Everything seems to be working find and dandy on my end. Please test.
unpatched 2.0.49_pre17 appears to be broken under some conditions, so be careful when trying
Created attachment 15347 [details, diff] portage.py-2.0.49_pre17-per_package_use_flags.patch I lied. This is the final version. This has some important fixes: - abstract the puse list generation into dep_getpuse() - use dep_getpuse() in emerge IUSE calculation, settings["PUSE"] defining and dep_check() myusesplit building. - ***fix ebuild.sh to respect PUSE settings in use(), and consequently in use_with() and use_enable()***
Created attachment 15348 [details, diff] emerge-2.0.49_pre17-per_package_use_flags.patch
Created attachment 15349 [details, diff] ebuild.sh-2.0.49_pre17-per_package_use_flags.patch
Nice patch, but I had problems with it for enabling specific USE flags (disabling worked fine). It could be caused by my USE="-*" setting in /etc/make.conf. It works if you change the last if-statement in dep_getpuse() from if z not in mylist and y not in mylist and z in usesplit: to if z not in mylist and y not in mylist: Not sure if this change might break something. Another thing is the color on emerge -vp for package disabled flags, it is extremely hard to read on a black background (I haven't seen the flags at all first). I changed darkblue to turquoise, it's readable even on a white background.
vapier@gentoo.org suggested that submit to this bug a related idea that I just posted on the dev list. My concern is that it is not just the USE variable that you might want to customize on a per package (or even ebuild) basis. My most frequent issue is to redefine ACCEPT_KEYWORDS per package. This is not possible at present: supplying ACCEPT_KEYWORDS=~arch affects also recursive dependencies. The generalization which I propose is to have the file: /etc/portage/package.env which contains "hunks". Each hunk starts with a package selection condition and the following lines consist of variable assignments. To reliably identify the start of a hunk, let's say that there must be an asterisk in column 0. So a hunk might look for example like: * >=category/package-version var1=val1 var2=val2 ... varn=valn What is the effects of hunks? for simplicity, I suggest to choose from the following two options: 1. either, only the first matching hunk applies 2. or, all matching hunks apply (last setting for a variable wins) I prefer option 1. A particularly useful application would be: * >=category/package-version ACCEPT_KEYWORDS=~x86 USE="..." what do you think? is this at all reasonable?
Maybe you could have the possibility of a hunk matching multiple packages by having a second (or more) line, starting with a + for extra packages
Marius: You're right. I'll post a new version with that modification. As far as the colors go, I don't care one way or the other. I just wanted to the new colors to be somewhat related to the current ones. Can't please everyone. :-) Denys, Paul: I don't know if we should introduce something that requires such stringent syntax. First of all there's no API in portage to handle such things, and second, I expect that there maybe a lot of syntax errors on the users' part which will result in tremendous amount of bug reports. Going further, what values would you want to override other than USE and ACCEPT_KEYWORDS on a per-package basis? CFLAGS? MAKEOPTS? AUTOCLEAN? I don't know if all that is necessary. Most of the build requirements should just be handled by the ebuild. Perhaps we should just leave this at USE and KEYWORDS. John and I briefly talked about it, and we may be able to pull off the per-package keywords functionality with /etc/portage/package.keywords (or package.accept or somesuch). How does that sound?
Hi Max, I don't really understand your "stringent syntax" remark. It is on the contrary completely straightforward and reuses the simplest fragment of syntax already in existence in portage: namely the package matching conditions such as >=cat/pkg-ver and the variable assignements var=val. The only syntax marker that I suggested was the asterisk in column 0 (properly speaking, it is not even necessary, but makes parsing into hunks utterly trivial). Also, my proposal has the ambition to solve simply, not only the USE and KEYWORDS problems that we have today, but also all the other similar package-specific settings that we may already have or will have in the future. Would it not be a little depressing if we had to introduce a /etc/portage/package.foo for every foo that is eventually decried as a sufficiently of a problem?
Your syntax would require a new parser while the current implementation uses a existing portage function to read the file. Using multiple simple files makes the parsing much easier. BTW, I've submitted a patch on bug 9379 for the mixed KEYWORDS problem. @Max: I got a traceback when I wanted to emerge -upvD world with package.use: emerge -upvD world These are the packages that I would merge, in order: Calculating world dependencies /Traceback (most recent call last): File "/usr/bin/emerge", line 2003, in ? if not mydepgraph.xcreate(myaction): File "/usr/bin/emerge", line 958, in xcreate if not self.create(myk): File "/usr/bin/emerge", line 679, in create if not self.select_dep("/",mydep["/"],myparent=mp): File "/usr/bin/emerge", line 777, in select_dep mycheck=portage.dep_check(depstring,self.mydbapi[myroot],parent=myparent) File "/usr/lib/python2.2/site-packages/portage.py", line 2650, in dep_check myusesplit.remove(x[1:]) ValueError: list.remove(x): x not in list It happens if I disable a flag in package.use that is not enabled in the global USE variable. If I change the code to just append -flags instead of removing flag it works as expected.
Marius, thank you for replying -- Denys, please see Marius's comments, those are my thoughts exactly. Marius and all: I saw that problem, and another one that John found. I have a fixed portage patch ready. I'll post it a bit later today. Also I have started doing the per-pkg keywords accept. Marius, I'll have a look at your work in a bit.
Marius and Max, the syntax I proposed is trivial to parse. I have of course prototyped a parser and I'll attach the code. Marius, I wish to stress that my proposal is completly in tune with your own contribution. I merely offer a more general package-specific information storage mechanism. It should be fairly straightforward to modify your code to use my storage mechanism. That is the whole point of my proposal. A very simple and nonetheless general way to stipulate package-specific settings. What to do with these settings is not part of the proposal. It is clear that portage can immediately use it (e.g. via your own contribution) to address various issues such as USE and KEYWORDS. Once such a mechanism is in place, it will certainly find other applications... e.g. possibly to affect ebuild variables, but that was not supposed to be part of my proposal.
Created attachment 15614 [details] a parser for /etc/portage/package.env a simple parser for the syntax I proposed for the hypothetical /etc/portage/package.env file for package-specific settings
Denys, I must admit your idea as to a solution to this problem is a lot more flexible and even forwarc compatible (in certain respects) to that of Max's efforts, although due to that very reason it has some fundamental flaws. 1) Customization of too much, making it impossible to debug. 2) Customization of things which violate portage policy (are made possible) 3) Those things other than USE, KEYWORDS and masking should be addressed as ebuild issues, and shouldnt be fixed in this manner. 4) It would be stepping away from the portage API. Extending the API would be a better solution, instead of having a completely new alternative 3rd party parser. If you are able to address the above issues this has potential, but i feel extending max's to other areas, such as KEYWORD (sorry i didnt check the one posted earlier yet) would be a neater.
Hi John, you have overestimated the scope of my proposal. I only propose a simple, uniform, flexible and extensible mechanism for supplying package-specific settings. I am not proposing specific applications beyond addressing USE and KEYWORDS at this point. Thus, in a first step, any settings other than for USE and KEYWORDS would simply have no effect. I wish to prevent the multiplication of specific hacks and instead provide a more general foundation on which to build, and possibly make other applications (not yet thought of) possible.
another possible application of my proposal would be to obsolete package.unmask: simply use a UNMASK=yes setting for the appropriate packages.
perhaps I should also point out that my parser allows the first hunk to have no condition. The idea is that this could be used for global settings (make.conf?).
Having configuration in more than one place is confusing and unnecessary from the user standpoint. USE and KEYWORD overriding has a specific purpose, as does package masking/unmasking, and the breakdown of where things go is clear and consise. Bundling it all into one file can quickly get out of hand. Aside from this, how would "emerge --info" look if all those things are allowed to be overridden? Some info has to show up there (USE/KEYWORD changes) other things don't (masking/unmasking). Where do you draw the line on what can be overridden and what cannot? I'd say we have to stop at USE/KEYWORDS -- anything else should be left to the ebuild, otherwise we're just asking for trouble. Besides that, it because an enourmous headache to maintain the code in portage (granted the parser is easy, but you also have to take user-defined package settings into consideration whenever you're looking at configurations -- CFLAGS, MAKEOPTS, etc). As John mentioned, the support and debugging becomes tremendously more difficult as well. Lets just stick with USE/KEYWORDS for now. The breakdown of file names are descriptive enough that one knows what goes where. Nick, any thoughts on this? Everyone, many appologies for not getting the new portage patch posted. I've been swamped with other things. Trying to dig myself out. It'll be here RSN(tm). :-)
your point about having configurations in more than one place causing confusion is well taken... but that's precisely my point. With my proposal, only one file is needed. You can get rid of the others. Your claim that putting this information in one file can get out of hand is arbitrary and unsubstantiated. We already want this information. I am just describing an extendable way to store it. The rest of your objections make little sense. The information which I have suggested to store in my format is currently scatered across many files, but it IS there (or will be shortly - one way or another) and portage DOES use it. With my proposal, the same information is there, but it is in one place. You keep harping negatively on the undesirability of other per-package variables customization and faulting my proposal for it... but that is NOT part of my proposal. I have stated this repeatedly. I am NOT suggesting that we use my proposal to permit per-package settings of CFLAGS or other things. It is a possibility, and perhaps one that should rightly be discounted, but it is NOT part of the proposal.
I dont have much time this morning so ill make this comment quick and to the point :) My biggest gripe, amongst anything else with the proposal of 1 single file for everything, is the requirement of a 3rd party parser. What Max is doing is extending portage functionality through existing API, this is the way i would prefer this to be handled. Extending the API to handle the fuctions shouldnt be done. for quite a few reasons. Its a nice idea, and we understand where your coming from, and perhaps in future it might be desired, but right now it isnt practical enough. especially when the solutions (to both problems?) exist.
Hi John, I quite understand the desire to provide additional functionality through the existing API. This is what Max does. My own proposal is indeed not aimed at providing additional functionality of this order, but rather at simplifying the foundation of the API. My primary motivation is to simplify the user's view of portage while providing a more flexible foundation for portage developers to build on. At present, there are many configuration files which the user can customize to affect portage, and more keep being invented. In as much as possible, I would like to consolidate and generalize this twisty maze of configuration files, and replace it with a single file. Very much in the spirit of the portage internals, this file should simply be regarded as a database.
Created attachment 15715 [details, diff] portage.py-2.0.49_pre17-per_package_use_flags.patch Here's the newest and shiniest version with the following changes: - fix dictionaries/lists trying to make it into the environment - fix per-package USE overriding global when global contains -* - enable per-package ACCEPT_KEYWORDS functionality by creating a /etc/portage/package.keywords with the following format: [mod]cat/pkg[-version] accept_keyword1 [accept_keyword2 ...] Where optional "mod" is the standard portage package range modifier (<=>).
Hi Max, I tested your patch. It applies cleanly and works like a charm. Very nice! It also illustrates what's not so nice about the multiplication of files. Now, in my package.unmask file I have: =cat/pkg1-ver0 =cat/pkg2-ver0 ... =cat/pkgN-ver0 (hum kde anyone? :-) and in my package.keywords file I have: =cat/pkg1-ver0 ~x86 =cat/pkg2-ver0 ~x86 ... =cat/pkgN-ver0 ~x86 and if I wanted specific USE settings, I'd probably have to repeat the same lines in my package.use file. Personally, I would prefer to state all this in one place. Using my proposal, I could just write: =cat/pkg1-ver0 =cat/pkg2-ver0 ... =cat/pkgN-ver0 UNMASK=yes ACCEPT_KEYWORDS=~x86
KDE isn't masked, it's just ~arched.
for a while it was masked. things change :-)
Max, I'd like a small extension if possible: if you don't specify any keywords for a package in package.keywords default to ~arch, it would simplify things without loosing flexibility. Another advantage would be that we could build somthing with x86 system and ~x86 world as requested in bug 21463 by symlinking package.keywords to /var/cache/edb/world :).
I want to "test" this enhancement. I am using ppc, and it is "unbearable" staying up to date on a few choice programs. This bug looks ready to be "integrated"? - I do not see why this depends on 3252. 3252 is non-trivial, additional functionality - obsolete "a parser for /etc/portage/package.env" - I do not like Marius' suggestion about default to ~arch as "ambiguity is evil" (tm). - discussion of "bug 21463" would just muddle the issues Failing that portage-2.0.49_pre17.ebuild no longer appears to be in the tree, can Max/someone else confirm/update the patch?
i can confirm that it applies cleantly to pre18
n00b: I accidently removed my copy of 2.0.29_pre18 and against 2.0.29_pre21 now ebuild.sh patch has a fuzz...and as far as I can tell breaks this func. If someone can tell me where to find the pre18.ebuild I would be thankful.
nvrmind: I cannot seem to get the original working anymore... so frustrating...the problem must be me. Cheers!
Created attachment 16609 [details, diff] portage.py-2.0.49-per_package_use_flags.patch bumping to work with portage-2.0.49
Created attachment 16610 [details, diff] emerge-2.0.49-per_package_use_flags.patch bumping to work with portage-2.0.49
Created attachment 16611 [details, diff] ebuild.sh-2.0.49-per_package_use_flags.patch bumping to work with portage-2.0.49
attachment #16609 [details, diff] attachment #16611 [details, diff] attachment #16610 [details, diff] do not work for me with portage-2.0.49 Can anyone confirm? I have USE="${USE} ( net-im/gaim -ssl ) ( sys-devel/gcc -java )" after all my global USE declarations in make.conf, but even "emerge -pv mozilla" says that it will be merged with -java and -ssl. Commenting the line above fixes it, so it seems I either got the syntax wrong or... :-/ I checked that the files installed on the system are really patched.
Just to confirm: you mean to say that all the patches apply cleanly but you're not seeing the expected results, yes? (I want to make sure the patches are clean.) As for why it isn't working: the per-package settings no longer go into the USE variable. They go into the /etc/portage/package.use file. See comment #24 and comment #36 for further reference.
Confirmed that it works using package.use. That last thing I had tried was the pre17 patch on portage pre18. It worked using the "USE=( cat/package flag1 )" syntax and there was no mention in the comments on the new patches for 2.0.49 that they require the package.use file. It only says "bump to 2.0.49". I personally don't like the idea of splitting use flags across different files, but that's just my preference. However, if all portage configuration went in /etc/portage one day (like moving make.* to /etc/portage) it would seem natural.
Ok... discovered the cause of my previous frustration. I did not have the emerge patch, only portage.py & ebuild.sh . Too bad bugzilla does not show relationship/association amongst the attachments. At 2.0.49 'package.use' works fine, but package.keywords does not seem to... anyone have diff exp? If so, please post example. I think I have tried all variations to package.keywords , but it currently reads: =gnome-extra/gnome-pilot-2.0.9 ~ppc dev-util/rapidsvn-0.2.0 ~ppc Neither line has the desired effect. Any help is greatly appreciated!
Try without the version. I.e, this one works for me: $ cat /etc/portage/make.keywords net-im/gaim ~x86 net-www/opera ~x86 sys-apps/lm-sensors ~x86 media-libs/alsa-lib ~x86 media-sound/alsa-driver ~x86 media-sound/alsa-utils ~x86 media-sound/alsa-tools ~x86 media-video/mplayer ~x86 media-video/transcode ~x86 x11-wm/windowmaker ~x86 x11-libs/lesstif ~x86 x11-misc/wmakerconf ~x86
Doh! Genone on #gentoo-portage was EXTREMELY helpful. The patch does appear to working correctly.
Created attachment 16768 [details, diff] combined patch including my proposed enhancement This patch combines the ebuild.sh / emerge / portage.py patches and includes the "default to ~arch" feature for package.keywords in my previous comment.
Marius, your combined patch applies to the CVS portage code but not to an installation of portage (different directory structure)
I know, I've taken it from my patchset. I don't think it's too hard to change the paths or use the -p1 option for patch.
Created attachment 17925 [details, diff] ebuild.sh+emerge-2.0.49-r4-per_package_use_flags.patch Treat this one with care. Changed to use the new "myuse" functionality in portage as of -r4. Not sure if I got everything right -- it works for me(tm).
Created attachment 17926 [details, diff] portage.py-2.0.49-r4-per_package_use_flags.patch And the portage part of the patch. Remember to apply both.
*** Bug 9379 has been marked as a duplicate of this bug. ***
Max, the 1st hunk for emerge does not apply cleanly to r10
Created attachment 19128 [details, diff] combined patch for portage -r12 This patch is against (masked) portage 2-0-49-r12. Because -r12 now installs the python modules in /usr/lib/portage/pym it also applies to an already installed portage version.
The colouring of the package-specific USE flags in the output of "emerge -pv" is not readable. Besides that, it would be more clear that the flags are *package-specific* if we used a different color. I would suggest yellow (the ample effect), as "always on" is green whilst "always off" is red.
*** Bug 32842 has been marked as a duplicate of this bug. ***
I had a general thought of adding a COLOR variable to /etc/make.conf that would have possible values of "light", "dark", and "none". So a person with a dark terminal background would set COLOR="light". I'll work on this and post another portage enhancement bug.
Including for -r17 for testing but some things need to get addressed. Add comments. Some things aren't obvious. Why does it ignore '-*' ? Don't add '-use' into the USE list. Is this only for display? self.configlist[-1]["PKGUSE"]=self.configlist[-1]["PKGUSE"]+"( "+x+" => "+string.join(pkgusesplit[x]," ")+" )"
*** Bug 33128 has been marked as a duplicate of this bug. ***
I just found out that +useflag syntax is ignored from /etc/portage/package.use ... Is this on purpose, or just a bug (of the patch?) ? I tried the following: kalin@sata kalin $ grep mutt /etc/portage/package.use net-mail/mutt +maildir +mbox +imap kalin@sata kalin $ emerge mutt -pv These are the packages that I would merge, in order: [ebuild R ] net-mail/mutt-1.5.4-r1 +ssl +nls +slang +cjk +crypt -imap -mbox +maildir kalin@sata kalin $ sed -i -e 's/+//g' /etc/portage/package.use kalin@sata kalin $ grep mutt /etc/portage/package.use net-mail/mutt maildir mbox imap kalin@sata kalin $ emerge mutt -pv These are the packages that I would merge, in order: [ebuild R ] net-mail/mutt-1.5.4-r1 +ssl +nls +slang +cjk +crypt +imap +mbox +maildir Any ideas?
I noticed that yesterday. I'll post a new patch today that contains this and some other fixes from Marius to address Nick's requests.
Created attachment 20637 [details] Diff for the modified per-package-use support
'+use' isn't really valid. I added a hack for that to the use support because no one reads docs apparently, and assume all visual accent output is perfectly legal input... I suppose doing the same for this wouldn't hurt either. I decided to hack things up a bit. package.use left side is a depend atom. Most specific atom is chosen to match a given package. sys-apps/portage =sys-apps/portage-2* =sys-apps/portage-2.0.49-r17 It can set anything for USE. -*, -USE, use, +use (With complaint) IUSE and depend is calculated using it. It's inherited. http://gentoo.twobit.net/portage/2.0.49-r15-perpkguse-1.diff
I made a snapshot with that diff in it. It includes all the current candidate code for -r17. copy -r15's or -r16's ebuild to -r62, and 'emerge --digest portage' might need to: echo "sys-apps/portage" >> /etc/portage/package.unmask
The patch is a bit large, but it makes improvements on class config that are geared toward killing globals.
Created attachment 20652 [details, diff] patch for package.keywords only as Nick's patch doesn't have the package.keywords functionality I made a seperate patch for it, should work with any recent portage version.
*** Bug 14741 has been marked as a duplicate of this bug. ***
*** Bug 33520 has been marked as a duplicate of this bug. ***
*** Bug 17024 has been marked as a duplicate of this bug. ***
Created attachment 21575 [details, diff] fixed package.keywords patch current CVS has a bug where packages can be unmasked accidently (notice that by unmasking <=dev-util/anjuta-1.1.98 dev-util/gambas also became unmasked). This patch has a workaround to fix that bug.
Created attachment 21577 [details, diff] another fix grr, that was the wrong function :(
Applying attachment #21577 [details, diff] from comment #103 on portage-2.0.49-r18 breaks stuff here: ===== chutz@lion chutz $ cat /etc/portage/package.keywords dev-libs/openssl chutz@lion chutz $ emerge -p openssh These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] net-misc/openssh-3.7.1_p2-r1 chutz@lion chutz $ emerge -p openssl These are the packages that I would merge, in order: Calculating dependencies !!! Problem in dev-libs/openssl dependencies. !!! unsubscriptable object ====== It seems only packages that appear in portage.keywords are broken. I also tried portage-2.50_pre1. According to the Changelog, the patch is already included there. It also gives the exact same error. I tried both with and without the ~x86 on the line. I cannot understand what kind of syntax I am supposed to follow. If I change the line in my package.keywords to dev-libs/openssl-* I get the following: ===== chutz@lion chutz $ emerge -pv openssl These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild UD] dev-libs/openssl-0.9.6k [0.9.7c-r1] 0 kB Total size of downloads: 0 kB chutz@lion chutz $ ACCEPT_KEYWORDS=~x86 emerge -pv openssl These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] dev-libs/openssl-0.9.7c-r1 0 kB Total size of downloads: 0 kB ===== This was for portage 2.0.50_pre1, but the output from a patched 2.0.49-r18 is similar.
Talking about portage-2.50_pre1 The problem from comment #104 seems to be in /usr/lib/portage/pym/portage.py in portdbapi.gvisible on the line saying: for mykey in pkgdict: if db["/"]["porttree"].dbapi.xmatch("bestmatch-list", mykey, None, None, [mycpv]) \ and catpkgsplit(dep_getcpv(mykey))[:2] == catpkgsplit(mycpv)[:2]: It gives the error when catpkgsplit(dep_getcpv(mykey)) == None and thus catpkgsplit(dep_getcpv(mykey))[:2] is unsubscriptable object or whatever the error was.
First off.... That's not a valid depend atom, so that won't ever work. dev-libs/openssl ~x86 It's fixed in cvs to tell you that it's wrong. It'll be out in 50_pre2 later today.
That's not a valid depend atom, so that won't ever work. dev-libs/openssl ~x86 It's fixed in cvs to tell you that it's wrong. It'll be out in 50_pre2 later today.
I was quite sure that it was I who was doing something wrong, but what do I have to put in package.keywords if I want to install the ~x86 masked version of openssl? "dev-libs/openssl ~x86" didn't work either.
try: >=dev-libs/openssl-0 ~x86
Could you also add documentation for this (and other /etc/portage files) to the manual pages of the portage package?
documentation is a different bug, search bugzilla for it
*** Bug 18826 has been marked as a duplicate of this bug. ***
*** Bug 21463 has been marked as a duplicate of this bug. ***
*** Bug 36970 has been marked as a duplicate of this bug. ***
can anybody tell me what the status of these patches are with respect to portage-2.0.49-r20? The portage ChangeLog doesn't say.
*** Bug 38302 has been marked as a duplicate of this bug. ***
*** Bug 3252 has been marked as a duplicate of this bug. ***
/etc/make.conf.d/ anybody?
no /etc/portage/ is nicer
