I have file /usr/local/fantoo/profiles/fantoo-stable/package.mask its my profile, in my overlay my profile has parent ../../../../../usr/portage/profiles/default-linux/x86/dev/2006.0 For example, I want unmask latest net-im/gaim masked by default gentoo profile package.mask. I create my /usr/local/fantoo/profiles/fantoo-stable/package.mask and append line -net-im/gaim no luck with unmasking. same if I create I create my /usr/local/fantoo/profiles/fantoo-stable/package.unmask and append line net-im/gaim Please, create solution.
Use /etc/portage/package.unmask to unmask packages and /etc/portage/package.keywords to add additional accepted keywords to individual packages. More information can be found in the Gentoo Handbook: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1#doc_chap4 and http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=3
(In reply to comment #1) > Use /etc/portage/package.unmask to unmask packages and > /etc/portage/package.keywords to add additional accepted keywords to individual > packages. More information can be found in the Gentoo Handbook: > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1#doc_chap4 > and http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=3 > his point being /etc/portage isn't portable, when he can just distribute his profile, perhaps even with his overlay. This is valid, was discussed on irc, and I have a patch, I'll attach it when I return home.
I don's see net-im/gaim anywhere in package.mask, so not sure what exactly you're after.
try use gstreamer we have mask >=media-libs/gstreamer-0.9.0 and want unmask via: -media-libs/gstreamer
Well, overlap checks won't be done with the current profile system, it can only handle overrides for syntactically equal lines, basically a unified diff. Basically needs a new profile subsystem for that way which won't appear anytime soon (and even then questionable). Adding package.unmask for profiles would be the easier route but then /etc/portage/package.mask might a problem (haven't looked at the code closely enough yet), will probably be required though if/when masking via packages gets deprecated/removed.
Marius, part of the problem was that /etc/portage/profile wasn't even being checked for p.mask ( hence the added location in the patch ) and IIRC grabfile_packages was stripping the - out of packagenames, meaning that later when the stacking occured things were not being over-riddent, hence the changed to grabfile as opposed to grabfile_packages. Now the latter part *may* be wrong,I probably spent only a bit of time looking at grabfile_packages, so I will double check the code there, but I know this patch works for me.
Heh, I don't even have a single clue what patch you're talking about ;) Nor do I think that what you described has something to do with this request.
(In reply to comment #7) > Heh, I don't even have a single clue what patch you're talking about ;) > Nor do I think that what you described has something to do with this request. > Arr I forgot to attach it but it was sent to the portage-dev ML :)
Not worth the effort.
(In reply to comment #2) > his point being /etc/portage isn't portable, when he can just distribute his > profile, perhaps even with his overlay. How is a profile that inherits from an x86 profile any more portable that /etc/portage? AFAICT /etc/portage can be redistributed just as easily as a profile in an overlay..
