Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 13616 - per package USE flags and KEYWORDS
Summary: per package USE flags and KEYWORDS
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage team
Keywords: InVCS
: 3252 9379 14741 17024 18826 21463 23925 32842 36970 (view as bug list)
Depends on: 3252
Blocks: 14741 18603 22559 33520
  Show dependency tree
Reported: 2003-01-09 22:21 UTC by Max Kalika (RETIRED)
Modified: 2011-10-30 22:18 UTC (History)
36 users (show)

See Also:
Package list:
Runtime testing required: ---

Attachments to allow for per-package USE flags (portage.py_per_package_use.patch,3.07 KB, patch)
2003-01-09 22:24 UTC, Max Kalika (RETIRED)
Details | Diff
emerge to allow for per-package USE flags (emerge_per_package_use.patch,503 bytes, patch)
2003-01-09 22:25 UTC, Max Kalika (RETIRED)
Details | Diff patch to allow per-package USE flags (portage.py_per_package_use.patch,3.07 KB, patch)
2003-01-13 11:28 UTC, Max Kalika (RETIRED)
Details | Diff
emerge patch to allow per-package USE flags (emerge_per_package_use.patch,503 bytes, patch)
2003-01-13 11:29 UTC, Max Kalika (RETIRED)
Details | Diff
update to latest portage and another feature (portage.py_per_package_use.2.patch,3.84 KB, patch)
2003-03-10 12:13 UTC, Max Kalika (RETIRED)
Details | Diff
update to latest portage and another feature (emerge_per_package_use.2.patch,992 bytes, patch)
2003-03-10 12:15 UTC, Max Kalika (RETIRED)
Details | Diff
updated and fixed patch (portage.py_per_package_use.3.patch,2.88 KB, patch)
2003-04-13 13:37 UTC, Max Kalika (RETIRED)
Details | Diff
updated and fixed emerge patch (emerge_per_package_use.3.patch,1.16 KB, patch)
2003-04-13 13:39 UTC, Max Kalika (RETIRED)
Details | Diff
new patch (portage.py_per_package_use.4.patch,4.16 KB, patch)
2003-05-21 12:24 UTC, Max Kalika (RETIRED)
Details | Diff
new emerge patch (emerge_per_package_use.4.patch,1.77 KB, patch)
2003-05-21 12:25 UTC, Max Kalika (RETIRED)
Details | Diff (,5.09 KB, patch)
2003-06-24 00:00 UTC, Max Kalika (RETIRED)
Details | Diff
emerge-2.0.48-r1-per_package_use_flags.patch (emerge-2.0.48-r1-per_package_use_flags.patch,1.77 KB, patch)
2003-06-24 00:01 UTC, Max Kalika (RETIRED)
Details | Diff (,1.98 KB, patch)
2003-07-11 14:43 UTC, Max Kalika (RETIRED)
Details | Diff
script to check flags (checkcurrentcustomflags,1.34 KB, text/plain)
2003-07-18 16:21 UTC, John Mylchreest (RETIRED)
try this one instead ;) (checkcurrentcustomflags) (checkcurrentcustomflags,1.35 KB, text/plain)
2003-07-18 16:28 UTC, John Mylchreest (RETIRED)
re-written, much faster, much nicer, and works properly? (checkflags,1.59 KB, text/plain)
2003-07-21 17:22 UTC, John Mylchreest (RETIRED)
checkflags (checkflags,1.92 KB, text/plain)
2003-07-22 09:40 UTC, John Mylchreest (RETIRED)
Details (,2.64 KB, patch)
2003-07-30 12:10 UTC, Max Kalika (RETIRED)
Details | Diff
emerge-2.0.48-r7-per_package_use_flags.patch (emerge-2.0.48-r7-per_package_use_flags.patch,1.92 KB, patch)
2003-07-30 12:11 UTC, Max Kalika (RETIRED)
Details | Diff (,323 bytes, patch)
2003-07-30 12:12 UTC, Max Kalika (RETIRED)
Details | Diff (,3.88 KB, patch)
2003-07-31 11:30 UTC, Max Kalika (RETIRED)
Details | Diff (,3.98 KB, patch)
2003-07-31 16:00 UTC, Max Kalika (RETIRED)
Details | Diff
emerge-2.0.48-r7-per_package_use_flags.patch (emerge-2.0.48-r7-per_package_use_flags.patch,1.82 KB, patch)
2003-07-31 16:00 UTC, Max Kalika (RETIRED)
Details | Diff (,3.68 KB, patch)
2003-08-01 17:15 UTC, Max Kalika (RETIRED)
Details | Diff
emerge-2.0.49_pre17-per_package_use_flags.patch (emerge-2.0.49_pre17-per_package_use_flags.patch,1.69 KB, patch)
2003-08-01 17:16 UTC, Max Kalika (RETIRED)
Details | Diff (,639 bytes, patch)
2003-08-01 17:17 UTC, Max Kalika (RETIRED)
Details | Diff
a parser for /etc/portage/package.env (,1.71 KB, text/plain)
2003-08-06 06:54 UTC, Denys Duchier
Details (,4.56 KB, patch)
2003-08-07 14:14 UTC, Max Kalika (RETIRED)
Details | Diff (,4.56 KB, patch)
2003-08-25 12:29 UTC, Max Kalika (RETIRED)
Details | Diff
emerge-2.0.49-per_package_use_flags.patch (emerge-2.0.49-per_package_use_flags.patch,1.65 KB, patch)
2003-08-25 12:30 UTC, Max Kalika (RETIRED)
Details | Diff (,439 bytes, patch)
2003-08-25 12:30 UTC, Max Kalika (RETIRED)
Details | Diff
combined patch including my proposed enhancement (package-use-keywords.patch,7.14 KB, patch)
2003-08-29 09:20 UTC, Marius Mauch (RETIRED)
Details | Diff (,2.22 KB, patch)
2003-09-17 15:49 UTC, Max Kalika (RETIRED)
Details | Diff (,4.13 KB, patch)
2003-09-17 15:50 UTC, Max Kalika (RETIRED)
Details | Diff
combined patch for portage -r12 (package-use-keywords.patch,6.86 KB, patch)
2003-10-12 05:10 UTC, Marius Mauch (RETIRED)
Details | Diff
Diff for the modified per-package-use support (the.diff,26.99 KB, text/plain)
2003-11-12 03:35 UTC, Nicholas Jones (RETIRED)
patch for package.keywords only (package.keywords.patch,1.23 KB, patch)
2003-11-12 15:03 UTC, Marius Mauch (RETIRED)
Details | Diff
fixed package.keywords patch (package.keywords.patch,1.29 KB, patch)
2003-12-01 23:05 UTC, Marius Mauch (RETIRED)
Details | Diff
another fix (package.keywords.patch,1.30 KB, patch)
2003-12-02 00:00 UTC, Marius Mauch (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Max Kalika (RETIRED) gentoo-dev 2003-01-09 22:21:33 UTC
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-

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"
Comment 1 Max Kalika (RETIRED) gentoo-dev 2003-01-09 22:24:49 UTC
Created attachment 7155 [details, diff] to allow for per-package USE flags

This is the main patch to 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. :-)
Comment 2 Max Kalika (RETIRED) gentoo-dev 2003-01-09 22:25:50 UTC
Created attachment 7156 [details, diff]
emerge to allow for per-package USE flags

one-line change in emerge needed to make this "motha" work.
Comment 3 Sven Vermeulen (RETIRED) gentoo-dev 2003-01-11 04:33:43 UTC
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

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.
Comment 4 Max Kalika (RETIRED) gentoo-dev 2003-01-11 22:52:06 UTC
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. :-)
Comment 5 Max Kalika (RETIRED) gentoo-dev 2003-01-13 11:28:13 UTC
Created attachment 7264 [details, diff] patch to allow per-package USE flags

update to portage-2.0.46-r6
Comment 6 Max Kalika (RETIRED) gentoo-dev 2003-01-13 11:29:07 UTC
Created attachment 7265 [details, diff]
emerge patch to allow per-package USE flags

update to portage-2.0.46-r6
Comment 7 Paul de Vrieze (RETIRED) gentoo-dev 2003-01-23 03:26:09 UTC
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
Comment 8 Max Kalika (RETIRED) gentoo-dev 2003-01-25 11:32:32 UTC
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).
Comment 9 Paul de Vrieze (RETIRED) gentoo-dev 2003-01-26 05:53:16 UTC
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
Comment 10 Matthew Humphrey 2003-02-04 21:58:46 UTC
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.
Comment 11 Max Kalika (RETIRED) gentoo-dev 2003-02-04 23:17:14 UTC
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. :-)
Comment 12 Paul de Vrieze (RETIRED) gentoo-dev 2003-02-05 03:26:01 UTC
I think he means /var/cache/edb/world . I think this is a good idea. It is easy
to implement and rather fool-proof
Comment 13 Max Kalika (RETIRED) gentoo-dev 2003-03-10 12:13:23 UTC
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)
Comment 14 Max Kalika (RETIRED) gentoo-dev 2003-03-10 12:15:50 UTC
Created attachment 9219 [details, diff]
update to latest portage and another feature

the associated patch to emerge to the 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-
Comment 15 Max Kalika (RETIRED) gentoo-dev 2003-04-13 13:37:42 UTC
Created attachment 10588 [details, diff]
updated and fixed 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:


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.
Comment 16 Max Kalika (RETIRED) gentoo-dev 2003-04-13 13:39:03 UTC
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.
Comment 17 Max Kalika (RETIRED) gentoo-dev 2003-05-21 12:24:18 UTC
Created attachment 12254 [details, diff]
new patch


  - update to portage 2.0.48
  - slightly cleaner usesplit copy ( myusesplit=usesplit[:] )
Comment 18 Max Kalika (RETIRED) gentoo-dev 2003-05-21 12:25:20 UTC
Created attachment 12255 [details, diff]
new emerge patch


  - update to portage 2.0.48
Comment 19 Norberto Bensa 2003-06-22 21:19:05 UTC
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. 
Comment 20 Max Kalika (RETIRED) gentoo-dev 2003-06-24 00:00:27 UTC
Created attachment 13752 [details, diff]

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.
Comment 21 Max Kalika (RETIRED) gentoo-dev 2003-06-24 00:01:34 UTC
Created attachment 13753 [details, diff]

same as the previous emerge patch, but this one is versioned for consistancy.
Comment 22 SpanKY gentoo-dev 2003-07-04 17:19:44 UTC
*** Bug 23925 has been marked as a duplicate of this bug. ***
Comment 23 John Mylchreest (RETIRED) gentoo-dev 2003-07-11 14:17:57 UTC
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.

Comment 24 Max Kalika (RETIRED) gentoo-dev 2003-07-11 14:43:15 UTC
Created attachment 14390 [details, diff]  

Ok, as John promised (thanks for your support!!!), here's the new new

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
  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.
Comment 25 Nicholas Jones (RETIRED) gentoo-dev 2003-07-16 01:19:15 UTC
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.

Comment 26 John Mylchreest (RETIRED) gentoo-dev 2003-07-18 16:21:20 UTC
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.
Comment 27 John Mylchreest (RETIRED) gentoo-dev 2003-07-18 16:28:12 UTC
Created attachment 14679 [details]
try this one instead ;) (checkcurrentcustomflags)
Comment 28 John Mylchreest (RETIRED) gentoo-dev 2003-07-18 17:02:12 UTC
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
Comment 29 Max Kalika (RETIRED) gentoo-dev 2003-07-18 17:15:58 UTC
Awesome!  I'm slowly working on carpaski's suggested additional features.  Hopefully 
I'll have a new patch soon. 
Comment 30 John Mylchreest (RETIRED) gentoo-dev 2003-07-21 17:22:45 UTC
Created attachment 14847 [details]
re-written, much faster, much nicer, and works properly?
Comment 31 John Mylchreest (RETIRED) gentoo-dev 2003-07-22 09:40:03 UTC
Created attachment 14873 [details]

now does some basic logic on the overlay also.
Comment 32 Max Kalika (RETIRED) gentoo-dev 2003-07-30 12:10:41 UTC
Created attachment 15239 [details, diff]   

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

So it now requires a one-line patch to (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.
Comment 33 Max Kalika (RETIRED) gentoo-dev 2003-07-30 12:11:55 UTC
Created attachment 15240 [details, diff]
Comment 34 Max Kalika (RETIRED) gentoo-dev 2003-07-30 12:12:29 UTC
Created attachment 15241 [details, diff]
Comment 35 Max Kalika (RETIRED) gentoo-dev 2003-07-31 11:30:24 UTC
Created attachment 15291 [details, diff]   

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.
Comment 36 Max Kalika (RETIRED) gentoo-dev 2003-07-31 16:00:15 UTC
Created attachment 15303 [details, diff]

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.
Comment 37 Max Kalika (RETIRED) gentoo-dev 2003-07-31 16:00:59 UTC
Created attachment 15304 [details, diff]
Comment 38 Max Kalika (RETIRED) gentoo-dev 2003-07-31 16:34:47 UTC
The three patches apply cleanly (with offsets) to the .49_pre17.  Everything seems to 
be working find and dandy on my end.  Please test. 
Comment 39 Paul de Vrieze (RETIRED) gentoo-dev 2003-08-01 02:17:51 UTC
unpatched 2.0.49_pre17 appears to be broken under some conditions, so be careful when trying
Comment 40 Max Kalika (RETIRED) gentoo-dev 2003-08-01 17:15:56 UTC
Created attachment 15347 [details, diff]

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 to respect PUSE settings in use(), and consequently in
   use_with() and use_enable()***
Comment 41 Max Kalika (RETIRED) gentoo-dev 2003-08-01 17:16:44 UTC
Created attachment 15348 [details, diff]
Comment 42 Max Kalika (RETIRED) gentoo-dev 2003-08-01 17:17:13 UTC
Created attachment 15349 [details, diff]
Comment 43 Marius Mauch (RETIRED) gentoo-dev 2003-08-04 00:36:23 UTC
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:
	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.
Comment 44 Denys Duchier 2003-08-04 17:39:18 UTC 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: 
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 
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 
what do you think? is this at all reasonable? 
Comment 45 Paul de Vrieze (RETIRED) gentoo-dev 2003-08-05 03:31:48 UTC
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
Comment 46 Max Kalika (RETIRED) gentoo-dev 2003-08-05 11:39:33 UTC
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? 
Comment 47 Denys Duchier 2003-08-05 12:30:21 UTC
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 
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/ for every foo that is 
eventually decried as a sufficiently of a problem? 
Comment 48 Marius Mauch (RETIRED) gentoo-dev 2003-08-06 05:53:15 UTC
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
  File "/usr/lib/python2.2/site-packages/", line 2650, in dep_check
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.
Comment 49 Max Kalika (RETIRED) gentoo-dev 2003-08-06 06:13:04 UTC
Marius, thank you for replying -- Denys, please see Marius's comments, those are my thoughts 

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.
Comment 50 Denys Duchier 2003-08-06 06:50:20 UTC
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. 
Comment 51 Denys Duchier 2003-08-06 06:54:01 UTC
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
Comment 52 John Mylchreest (RETIRED) gentoo-dev 2003-08-06 08:58:09 UTC
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.
Comment 53 Denys Duchier 2003-08-06 09:17:13 UTC
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 
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. 
Comment 54 Denys Duchier 2003-08-06 10:48:22 UTC
another possible application of my proposal would be to obsolete 
package.unmask: simply use a UNMASK=yes setting for the appropriate 
Comment 55 Denys Duchier 2003-08-06 13:22:51 UTC
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?). 
Comment 56 Max Kalika (RETIRED) gentoo-dev 2003-08-06 15:09:12 UTC
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). :-) 
Comment 57 Denys Duchier 2003-08-06 16:51:58 UTC
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. 
Comment 58 John Mylchreest (RETIRED) gentoo-dev 2003-08-07 02:05:30 UTC
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.
Comment 59 Denys Duchier 2003-08-07 03:29:13 UTC
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. 
Comment 60 Max Kalika (RETIRED) gentoo-dev 2003-08-07 14:14:05 UTC
Created attachment 15715 [details, diff]  

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 (<=>).
Comment 61 Denys Duchier 2003-08-08 01:56:28 UTC
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: 
(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: 
Comment 62 Max Kalika (RETIRED) gentoo-dev 2003-08-08 06:50:54 UTC
KDE isn't masked, it's just ~arched.
Comment 63 Denys Duchier 2003-08-08 07:12:43 UTC
for a while it was masked. things change :-) 
Comment 64 Marius Mauch (RETIRED) gentoo-dev 2003-08-08 08:39:45 UTC
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 :).
Comment 65 Lloyd D Budd 2003-08-18 22:51:48 UTC
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?
Comment 66 John Mylchreest (RETIRED) gentoo-dev 2003-08-19 04:43:46 UTC
i can confirm that it applies cleantly to pre18
Comment 67 Lloyd D Budd 2003-08-22 11:56:46 UTC
n00b: I accidently removed my copy of 2.0.29_pre18 and against 2.0.29_pre21 now 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.
Comment 68 Lloyd D Budd 2003-08-22 16:46:28 UTC
nvrmind: I cannot seem to get the original working anymore... so frustrating...the problem must be me.  Cheers!
Comment 69 Max Kalika (RETIRED) gentoo-dev 2003-08-25 12:29:10 UTC
Created attachment 16609 [details, diff]

bumping to work with portage-2.0.49
Comment 70 Max Kalika (RETIRED) gentoo-dev 2003-08-25 12:30:00 UTC
Created attachment 16610 [details, diff]

bumping to work with portage-2.0.49
Comment 71 Max Kalika (RETIRED) gentoo-dev 2003-08-25 12:30:29 UTC
Created attachment 16611 [details, diff]

bumping to work with portage-2.0.49
Comment 72 Georgi Georgiev 2003-08-25 16:07:12 UTC
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.
Comment 73 Max Kalika (RETIRED) gentoo-dev 2003-08-25 16:20:52 UTC
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 
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. 
Comment 74 Georgi Georgiev 2003-08-25 16:37:34 UTC
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.
Comment 75 Lloyd D Budd 2003-08-28 07:50:01 UTC
Ok... discovered the cause of my previous frustration.  I did not have the emerge patch, only & .  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!
Comment 76 Georgi Georgiev 2003-08-28 09:19:36 UTC
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
Comment 77 Lloyd D Budd 2003-08-28 10:05:29 UTC
Doh!  Genone on #gentoo-portage was EXTREMELY helpful.  The patch does appear to working correctly.  
Comment 78 Marius Mauch (RETIRED) gentoo-dev 2003-08-29 09:20:58 UTC
Created attachment 16768 [details, diff]
combined patch including my proposed enhancement

This patch combines the / emerge / patches and includes
the "default to ~arch" feature for package.keywords in my previous comment.
Comment 79 Denys Duchier 2003-09-01 05:00:55 UTC
Marius, your combined patch applies to the CVS portage code 
but not to an installation of portage (different directory structure) 
Comment 80 Marius Mauch (RETIRED) gentoo-dev 2003-09-07 19:00:19 UTC
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.
Comment 81 Max Kalika (RETIRED) gentoo-dev 2003-09-17 15:49:31 UTC
Created attachment 17925 [details, diff]

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).
Comment 82 Max Kalika (RETIRED) gentoo-dev 2003-09-17 15:50:09 UTC
Created attachment 17926 [details, diff]

And the portage part of the patch.  Remember to apply both.
Comment 83 Marius Mauch (RETIRED) gentoo-dev 2003-10-09 13:35:34 UTC
*** Bug 9379 has been marked as a duplicate of this bug. ***
Comment 84 Denys Duchier 2003-10-12 04:21:26 UTC
Max, the 1st hunk for emerge does not apply cleanly to r10
Comment 85 Marius Mauch (RETIRED) gentoo-dev 2003-10-12 05:10:25 UTC
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.
Comment 86 Alexander Papaspyrou 2003-11-01 03:46:05 UTC
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.
Comment 87 Marius Mauch (RETIRED) gentoo-dev 2003-11-06 08:56:21 UTC
*** Bug 32842 has been marked as a duplicate of this bug. ***
Comment 88 Max Kalika (RETIRED) gentoo-dev 2003-11-06 10:11:12 UTC
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.
Comment 89 Nicholas Jones (RETIRED) gentoo-dev 2003-11-09 22:49:31 UTC
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],"
")+" )"

Comment 90 SpanKY gentoo-dev 2003-11-10 06:37:47 UTC
*** Bug 33128 has been marked as a duplicate of this bug. ***
Comment 91 Kalin KOZHUHAROV 2003-11-11 00:18:58 UTC
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?

Comment 92 Max Kalika (RETIRED) gentoo-dev 2003-11-11 08:51:55 UTC
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.
Comment 93 SpanKY gentoo-dev 2003-11-11 11:54:04 UTC
*** Bug 33128 has been marked as a duplicate of this bug. ***
Comment 94 Nicholas Jones (RETIRED) gentoo-dev 2003-11-12 03:35:50 UTC
Created attachment 20637 [details]
Diff for the modified per-package-use support
Comment 95 Nicholas Jones (RETIRED) gentoo-dev 2003-11-12 03:36:09 UTC
'+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.


It can set anything for USE. -*, -USE, use, +use (With complaint)

IUSE and depend is calculated using it.
It's inherited.
Comment 96 Nicholas Jones (RETIRED) gentoo-dev 2003-11-12 03:42:31 UTC
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

Comment 97 Nicholas Jones (RETIRED) gentoo-dev 2003-11-12 03:45:58 UTC
The patch is a bit large, but it makes improvements on class config
that are geared toward killing globals.
Comment 98 Marius Mauch (RETIRED) gentoo-dev 2003-11-12 15:03:16 UTC
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.
Comment 99 Marius Mauch (RETIRED) gentoo-dev 2003-11-15 19:32:29 UTC
*** Bug 14741 has been marked as a duplicate of this bug. ***
Comment 100 Marius Mauch (RETIRED) gentoo-dev 2003-11-17 10:19:00 UTC
*** Bug 33520 has been marked as a duplicate of this bug. ***
Comment 101 Marius Mauch (RETIRED) gentoo-dev 2003-11-28 02:17:41 UTC
*** Bug 17024 has been marked as a duplicate of this bug. ***
Comment 102 Marius Mauch (RETIRED) gentoo-dev 2003-12-01 23:05:25 UTC
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.
Comment 103 Marius Mauch (RETIRED) gentoo-dev 2003-12-02 00:00:33 UTC
Created attachment 21577 [details, diff]
another fix

grr, that was the wrong function :(
Comment 104 Georgi Georgiev 2003-12-11 23:15:53 UTC
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
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.
Comment 105 Georgi Georgiev 2003-12-12 00:40:37 UTC
Talking about portage-2.50_pre1

The problem from comment #104 seems to be in /usr/lib/portage/pym/ 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.
Comment 106 Nicholas Jones (RETIRED) gentoo-dev 2003-12-12 08:49:31 UTC
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.
Comment 107 Nicholas Jones (RETIRED) gentoo-dev 2003-12-12 11:14:51 UTC
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.
Comment 108 Georgi Georgiev 2003-12-12 17:40:38 UTC
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.
Comment 109 Max Kalika (RETIRED) gentoo-dev 2003-12-12 17:43:11 UTC

>=dev-libs/openssl-0  ~x86
Comment 110 Paul de Vrieze (RETIRED) gentoo-dev 2003-12-13 06:45:42 UTC
Could you also add documentation for this (and other /etc/portage files) to the manual pages of the portage package?
Comment 111 SpanKY gentoo-dev 2003-12-13 08:32:47 UTC
documentation is a different bug, search bugzilla for it
Comment 112 Marius Mauch (RETIRED) gentoo-dev 2003-12-22 21:51:01 UTC
*** Bug 18826 has been marked as a duplicate of this bug. ***
Comment 113 SpanKY gentoo-dev 2003-12-22 22:03:40 UTC
*** Bug 21463 has been marked as a duplicate of this bug. ***
Comment 114 SpanKY gentoo-dev 2004-01-01 16:38:13 UTC
*** Bug 36970 has been marked as a duplicate of this bug. ***
Comment 115 Denys Duchier 2004-01-06 05:33:39 UTC
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.
Comment 116 Marius Mauch (RETIRED) gentoo-dev 2004-01-15 09:53:09 UTC
*** Bug 38302 has been marked as a duplicate of this bug. ***
Comment 117 Marius Mauch (RETIRED) gentoo-dev 2004-01-25 09:36:11 UTC
*** Bug 3252 has been marked as a duplicate of this bug. ***
Comment 118 Aaron Peterson 2004-03-05 23:34:11 UTC
/etc/make.conf.d/ anybody?
Comment 119 SpanKY gentoo-dev 2004-03-05 23:37:25 UTC
no /etc/portage/ is nicer