Sorry it's faster to quote the irc log of this vs typing it out all over again. ------------------------------------------------------------------------------- <jstubbs> package.mask should be per profile and split out from packages. package.unmask, i think is bad. <solar> package.keywords <jstubbs> in the profiles? <solar> that one for sure... Whats (un)stable for x86-glibc wont be the same for x86-uclibc or x86-bsdlibc <solar> and till such a time as another type of keywording system exists we will need to declare some ~arch as safe for some profiles. <jstubbs> is how all that's going to be supported been decided? i thought it was still floating.. <solar> jstubbs: I'm not sure whats been decided.. I know people love to talk about things and do nothing <solar> I love to do stuff and talk about almost nothing ;) <jstubbs> solar: sounds familiar <solar> jstubbs: would it be hard to get a package.keywords on a per profile basis? <solar> does the idea make your head spin? <jstubbs> solar: not really. <jstubbs> solar: approximately 10 characters in 1 line of portage sort of not really. <jstubbs> solar: file a bug and include comments for any package.* you think is necessary. essentially, carpaski has to approve this one and a bug is the easiest way to manage it. -------------------------------------------------------------------------- I'd really opt for profiles supporting everything that's supported in /etc/portage/ on a cascading type of basis, but for now the above (libcs) makes the basic case for need of package.keywords
package.mask is a blanket mask and isn't for arbitrary use. I'm not sure I understand why you want to manipulate it on a profile level... arch = stable ~arch = testing -arch = broken/not-functional/unfixable package.mask = dangerous or has an explicit issue Security uses removal and package.mask to make it mostly obvious that something is really broken or dangerous. Having it per-profile is likely to get it lost, missed, or neglected. I use package.mask to prevent people from accidentally getting unstable portages. It's a preventative measure, not an everyday feature or function. You'll need a really good reason and support from others for this one. Cascading is possible, but still bothers me.
As noted above what will be stable on x86-glibc will not be the same as what's going to be considered stable on other build scenario's or even a high/low enough version to even compile for the same arch. net-snmp for example would not even build with x86:uclibc but builds and runs fine with the ~arch version (this package was later bumped to stable, but we don't have that luxury for all effected packages. sys-apps/busybox-0.60.3-r1 is stable on x86:glibc and is this way for the livecd's people, however if we were in the future wanted to use portage with the power of the cascading profile the embedded herd would need >=sys-apps/1.00_pre8 and could use per profile package keywords for just this. This and other cases for all of /etc/portage/package.* will become apparent when we start getting three or more levels deep in a cascading profile. The package.keywords in my minds eye could pretty much serve in the migration to stable on in when needed in a profile without forcing users to run and accept all of ~arch. Note this chicken egg & game could also be solved with a package.env if that existed on a per profile basis.
it would be very useful to keyword gcc 3.4 but still mask it in each individual non-gcc-3.4 profile. per-profile package.keywords could probably also be useful for similar purposes...
Somehow this sounds like GLEP22 territory ...
Seeing all the bugs/requests pop up recently I'd really prefer to see a per profile package.env (from there we could easly control blah and not keep having to open bugs for per profile requests) GLEP 22 is not all that ideal solution for us either as it requires sub arch maintainers to have to edit every single ebuild in the port tree for the same arch 80% of the time this is unneeded for the above.. Unless we plan on deploying more than one keyword make.defaults (which was not clearly stated in GLEP 22) ACCEPT_KEYWORDS="x86 x86:uclibc"
What's going on with this bug... solar?
It appears to be just sitting. Seems there are mixed feelings within the dev portage team about having profiles behave the same as /etc/portage/*
Time for a vote? ;)
I vote YES
This could be implemented in much the same way that package.use.mask/package.use.force are implemented. It would add some additional overhead to the portdbapi matching/visibility calculations. We should at least have a discussion on the gentoo-dev ml prior to adding a profile extension like this, especially considering the way that it overlaps with glep 22.
package.unmask is a no go IMO, it would require a complex stacking layer with overlap checks to work properly. package.mask exists and is used. package.use exists but isn't used yet. package.keywords ... don't know if I like the idea of that file in profiles, could become quite confusing. Needs a -dev discussion at least IMO.
I forgot about this bug. But from time to time the desire for p.keywords on a per profile basis comes up. Mainly to remove stable markings vs having to p.mask things which are not really stable under uclibc or hardened.
I'm planning to implement this very soon now.
*** Bug 237917 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > I'm planning to implement this very soon now. Thanks! Will it make it into 2.2 final? :)
(In reply to comment #15) > (In reply to comment #13) > > I'm planning to implement this very soon now. > > Thanks! Will it make it into 2.2 final? :) Zac?
Yes, putting it in 2.2 final is doable. I'll try to get it done pretty soon.
I owe you a beer if that happens, so if you come to FOSDEM 2009.... ;)
Just also voting that this would be a very nice feature.
Created attachment 177944 [details, diff] support package.keywords in profiles (applies against 2.1.6.4 and 2.2_rc20) If this is saved as /tmp/profile_keywords.patch, then it can be applied as follows: cd /usr/lib/portage patch -p0 < /tmp/profile_keywords.patch In profiles, package.keywords modifies effective KEYWORDS values for a given ebuild. This behavior is notably different from /etc/portage/package.keywords, which instead modifies effective ACCEPT_KEYWORDS.
Created attachment 177946 [details, diff] support package.keywords in profiles (applies against 2.1.6.4 and 2.2_rc20) This update fixes a major bug. It should work fine now.
This is fixed in 2.1.6.5 and 2.2_rc21.
(In reply to comment #22) > This is fixed in 2.1.6.5 and 2.2_rc21. Does not work here using 2.2_rc33 :-( How can I debug this?
(In reply to comment #23) > (In reply to comment #22) > > This is fixed in 2.1.6.5 and 2.2_rc21. > > Does not work here using 2.2_rc33 :-( > How can I debug this? I tried with package.keywords both as a file and as a directory inside the profile directory.
(In reply to comment #24) > (In reply to comment #23) > > (In reply to comment #22) > > > This is fixed in 2.1.6.5 and 2.2_rc21. > > > > Does not work here using 2.2_rc33 :-( > > How can I debug this? > > I tried with package.keywords both as a file and as a directory > inside the profile directory. Ok, the bug is as follows: package.keywords inside a profile *requires* a keyword (example: "=sys-apps/portage-2.2* x86") as opposed to package.keywords in /etc/portage (example: "=sys-apps/portage-2.2*") Can this please be fixed to create a consistent behaviour across package.keywords in any location? :) Thanks!
I think the way it works right now makes sense and is consistent with the KEYWORDS variable of an ebuild. Three levels of keywording: missing keyword, testing~, and stable. The current behavior inherits KEYWORDS from the ebuild which can then be modified in all ways. Ex: ebuild KEYWORDS="~arm amd64 ~mips ppc ~sparc x86" package.keywords entry: <cat/pkg> -arm -amd64 ~hppa ia64 mips ~ppc result KEYWORDS="~hppa ia64 mips ~ppc ~sparc x86" arm,amd64 are reduced to missing keyword from testing and stable respectively. mips is promoted from testing to stable. ppc is demoted from stable to unstable. hppa is added to testing. ia64 is added to stable. sparc,x86 remain untouched at testing and stable respectively. I like it and will be putting it to use on hardened. What is the change to the way this operates that you propose precisely?
(In reply to comment #25) > Can this please be fixed to create a consistent behaviour > across package.keywords in any location? :) The implementation details are entirely different for package.keywords in profiles. In profiles, package.keywords causes changes to the effective KEYWORDS, while package.keywords in /etc/portage causes changes to the effective ACCEPT_KEYWORDS. I suppose that we could add support for package.accept_keywords in the profiles.
(In reply to comment #27) > (In reply to comment #25) > > Can this please be fixed to create a consistent behaviour > > across package.keywords in any location? :) > > The implementation details are entirely different for package.keywords in > profiles. In profiles, package.keywords causes changes to the effective > KEYWORDS, while package.keywords in /etc/portage causes changes to the > effective ACCEPT_KEYWORDS. I suppose that we could add support for > package.accept_keywords in the profiles. Yeah, right -- I was always thinking of per-profile package.keywords in the same way as /etc/portage/package.keywords works. D'oh :) Having 1 name for 2 different files is confusing... But anyway, yes, I would want a package.accept_keywords (shouldn't we rename /etc/portage/package.keywords to package.accept_keywords as well then?). Maybe I have to think about it some more. The only reason *I* want per-profile package.(keywords/accept_keywords) is that I want to be able to "just emerge" certain packages that are still marked ~arch in the upstream portage tree. I'm using this for a centralized build environment producing binary packages for binhost client systems (servers and workstations with several different custom profiles).
Closing as package.keywords support is already included. File a new bug if you want package.accept_keywords for profiles (would behave similarly to /etc/portage/package.keywords).
> ebuild KEYWORDS="~arm amd64 ~mips ppc ~sparc x86" > > package.keywords entry: > <cat/pkg> -arm -amd64 ~hppa ia64 mips ~ppc > > result KEYWORDS="~hppa ia64 mips ~ppc ~sparc x86" > Small correction for anyone using this as a ref instead of the portage manpage. Should look like this: ebuild KEYWORDS="~arm amd64 ~mips ppc ~sparc x86" package.keywords entry: <cat/pkg> -arm -amd64 ~hppa ia64 mips -ppc ~ppc result KEYWORDS="~hppa ia64 mips ~ppc ~sparc x86" The difference is the addtion of -ppc in the package.keywords entry. It is necessary to first remove the stable keyword.
