Talk:TIP Dealing with masked packages

You must prepend specific versions with one of =, <=, >=, < or >. Note that you can also use the ~ operator and omit the "-r#" part to mean "any revision of this version".

--AllenJB 15:43, 8 September 2007 (UTC)

[edit] my way

My way isn't really a different way, it's just a script to echo it in to /etc/portage/* for you..

[edit] script for hard masked packages

Hi, I noticed you made a script for package.keywords but not for package.unmask
I made one for myself but I think it could benefit more than myself :) I am really sorry but I don't have time to fit it in nicely into the actual wiki page so I'll just link you to were I posted it. If I have time later on, and I see nobody has done it, I will do it myself. Script For Unmasking.
UPDATE: OK done it. think it fits in smoothly... :)

This links to a site you have to login to. Can you please post your script to the wiki? Currently no one can get to it...--Herda05 05:36, 23 February 2006 (GMT)

Sorry about that, I've updated the link (again). -- drax, 14 February 2008

[edit] my way (new)

credits to Gherald (f.k.a FreeIX) for the latest version of the gimme.sh script, and flawless package matching.
I posted the unmask.sh, and have been using my own equivalent of the gimme.sh script (up to now). I think a few things, in the gimme.sh script could be done diffenrently. I'll just list them.

1. To match the package, and to extract the full name (including category) you use an emerge --pretend. This actually makes the execution of the script ALOT longer than it should.
   1. The script *could* search /usr/portage instead. This would be faster, but make the script more complex. I thought it best to let portage deal with this. Subsequent emerges (after the --pretend) should be faster since things are cached --Gherald
2. At the end of the script, you actually start to emerge the packet. More often than not, I don't actually want to emerge the package i'm trying to mark stable (i'm just marking a dependency stable).
   1. That is the original behavior of the script. The 5-second delay presents you with an oportunity to Ctrl+C and abort the operation. I think this suits most people's needs. --Gherald
3. The script isn't very open to later features (like allowing the user to stabilize just a version, or revision bumps, or every upcoming version)...
   1. Scripting that functionality would be over the top. Simply edit package.keywords manually in such instances. --Gherald

For packet matching, my script simply needs the user to specify the category. He would have had to type it anyway, had he edited his package.keywords by hand, and he can see the package-category/package-name in the emerge error message (telling him that the package is masked by the ~x86 keyword).
Don't emerge pretend (it can take very long if the package has alot of dependencies), just stick whatever the user feeds you (after matching against existing entries) in the package.keywords file
If you really want to verify the existence of the package, I suggest you use the local portage tree in the filesystem ($PORTDIR, ...).
Additionally, I don't think the script should emerge the packet, it should only add the entry, marking it stable. As stated earlier, most of the time I use this script, the package I am trying to emerge is not the one I'm marking stable with the script (only a dependency). Moreover, this script should take very little time to execute.
Finally, don't you think it's silly to lose so much freedom of choice, just because we're using a script. I think this script could (read: should) be made to accept a few options, allowing the user to specify what he wants to mark stable (just one version maybe, or maybe all, etc).
So what do people think? Should we? Or should we simply make two scripts? After all, gentoo is all about choices...
In any case, I'd really like to hear what anyone thinks, specially FreeIX and contributors. drax[at]sweon[dot]net

Not sure where to put this query in here - but there's a bit that states 'since this is run as root, it should be in /bin' ... um, what? Traditionally, root only scripts go into sbin... bin would be in everyone's path. I know some folks just put sbin in their path too, but... not the question. The question is WHY is that suggestion there - i.e. WHAT does one gain from putting it in /bin ? I certainly am not seeing anything which indicates additional functionality in /bin, and of course it runs just fine from whatever directory via explicitly stating the path - so I'm very, very confused by the 'needs to be in /bin' statement. I'd remove it, but I figure there MUST be a reason someone said that (perhaps it's a mistake...)

[edit] Other Masks

You have put in ~keyword masks but not ~arch or -* keyword 80.42.81.165 13:47, 9 Apr 2005 (GMT)

Missing keywords are also not mentioned.

I want to know how to unmask these also --81.178.112.8 21:42, 22 September 2005 (GMT)

There have been questions about the "-*" mask. This one seems very poorly documented. I am not a gentoo expert, but at least to get the discussion going, it seems you can unmask these -* packages by: echo "sys-devel/gcc -*" >> /etc/portage/package.keywords

Also, it seeems like specifying a version does not work - e.g. echo "sys-devel/gcc-4.0.2.-r3 -*" >> /etc/portage/package.keywords did not work for me. After unmasking the generic package, I had other packages to unmask, but it worked.

[edit] Equal sign for exact package version

Shouldn't we prepend the line by an equal sign = in package.unmask when specifying the exact version?

[edit] inclusion in gentoolkit

unmask should be part of the gentoolkit. I like Gentoo/portage because it's pretty good at avoiding dependency issues, but dodging masked packages can be a real hassle.

== completely flawed is the Gentoo masking program. This should be replace with a force of -f. ex. echo "net-p2p/wire-1.0.2 ~*" >> /etc/portage/package.keyword echo "net-p2p/wire-1.0.2 ~*" >> /etc/portage/package.keywords echo "net-p2p/wire-1.0.2 ~*" >> /etc/portage/package.mask echo "net-p2p/wire-1.0.2 ~*" >> /etc/portage/package.unmask echo "net-p2p/wire" >> /etc/portage/package.keyword echo "net-p2p/wire" >> /etc/portage/package.keywords echo "net-p2p/wire" >> /etc/portage/package.unmask echo "net-p2p/wire" >> /etc/portage/package.mask

you name it, will all yeild !!! All ebuilds that could satisfy "net-p2p/wire" have been masked. !!! One of the following masked packages is required to complete your request: - net-p2p/wire-1.0.2 (masked by: missing keyword)

what a pain, this entire masking stage should be dropped like a rock!