current possible requirements that i can think of: specify portage versions that are affected (i.e. DEPEND atoms) optional bug field (for when theres a bug on bugs.gentoo.org for it) warn users who already have the package installed (perhaps after every `emerge sync`) warn users who will be installing the package and force the user to say 'yes' to an interactive prompt in order to merge the package
Instead of a specific bug field, wouldn't it be more useful to extend the package.mask file format to include a generic comment field? It'd be nice to see a brief comment on why a particular package/version is masked instead of "all ebuilds that could satisfy package have been masked." Also, I don't think an interactive "yes" is the way to go for protecting users from themselves. Differentiating security.mask from package.mask by making it ignore package.unmask would force the user to either edit security.mask or run ebuild directly (which should complain very loudly, like emerge depclean does). This is about as much as one can hope to protect a user from him/herself.
package.mask already has comments why somethong is masked, it's just not shown by emerge. Also why should it ignore package.unmask, both solutions you offered are nasty hacks (one which is only temporary, the other is discouraged by every dev for normal usage as it's for ebuild testing ONLY). If you already unmasked a package with package.unmask you obviously don't care about problems with it. The only difference between package.mask and security.mask that I see is the additional warning if the package is already installed (as I also don't think a yes/no prompt is a good idea).
an additional difference would be the ability to explicitly bypass security.mask by emerge --ignore-security-mask or some such. this would be required for people who don't really care about security, but to still acknowledge the risk.. furthermore, the idea of another file was so that it is a seperate file on cvs.g.o with permissions set so that only people in the security group can edit it
(slightly OT) I think comment #1 is valid. Why not have a field in {package,security}.mask that is read and printed by Portage when the "packages are masked" error shows up? There are comments already, it's just not obvious where to find them. Is there a reason to not print them automatically?
Created attachment 28497 [details, diff] Patch to show comments from package.mask With this patch applied emerge will print the comment from package.mask if it encounters a hardmasked package.
For some reason this double-prints the comment for utempter and xterm.
Created attachment 28612 [details, diff] updated patch to show comments only once Well, if the mask affects several versions the comment is shown for each version. New patch only shows the comment for the first version.
Right, I figured that out about five seconds after posting, but I still think the updated version (only showing the comment once even with multiple versions) makes more sense. What happens if multiple versions are masked in separate sections of package.mask with different comments?
if the comment isn't the same it will be shown (as in the code: if comment != oldcomment ;)
how are we doing on this? Is the code ready to be patched into portage and be released?
I don't like to use comment string as system message. And I agree with comment #1.
You only mean the comment sign or the text in general ? Also which parts of comment #1 do you agree on ? The main reason why I don't want a new file is compatibility as many tools would have to be changed and also old portage versions will ignore it, so it's not safe to use for quite some time (I recommend 3 months at least before depending on specific portage features)
genone's patch is included for 2.0.51_pre3... I am not a particular fan of security.mask either.
this is included in portage -- just waiting for .51 to get released and stable. closing bug.
