Michał Górny posted on Sun, 02 Dec 2012 09:35:45 +0100 as excerpted: > On Sun, 2 Dec 2012 02:20:07 +0000 (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > >> Rich Freeman posted on Sat, 01 Dec 2012 08:46:34 -0500 as excerpted: >> >> > And if we force some types of packages to be masked all the time, >> > then what do we do if we actually need to mask them for removal or >> > security.
>> Very good point. >> What about this for a reasonable but still somewhat strict compromise? >> >> a) A pkg_pretend phase that checks for a set variable (like >> I_KNOW_THE_SECURITY_ISSUES), and dies with an appropriate warning if >> it's not set. >> >> b) With (a) in place, keeping the package unmasked (unless (c)) but >> forever ~arch, no stable. > > You just requested us to have a package which intentionally fails to > build by default. And we're not supposed to fix this nor mask it... That's what pkg_pretend is FOR, to notify users about seriously out of the ordinary situations such as incredibly resource-intensive builds, or unusual packages that might place their system in danger, that need some manual attention in the pretend phase, before the actual build gets under way. They'll deal with it once, before the install starts, either deciding to set the variable, or deciding the risk is too great and that they don't need the package /that/ much after all. Either way, they'll be informed about the risks and won't have to worry about it again during routine use and updates, but if they do choose to install, will still be informed by the usual security mask mechanism if there's an actual known vulnerability. I actually have some experience with such variables as I've set the I_KNOW_WHAT_I_AM_DOING var for glibc so I can downgrade back to the very same binpkg I was using just minutes before, when I find a problem with an upgrade. I understand why the variable test is there for glibc, but it was irritating non-the-less, especially since simply setting it when I had the problem wouldn't work, since it wasn't set in the binpkg. I have similar var settings for grub, so it doesn't try to mount /boot. But setting a variable for a single package via /etc/portage/env/* and rebuilding "just works" and must be done only once. No further worries about it after that. Basically it's the same thing as having to accept a license before first install, only in this case it's effectively that they have to accept a gentoo warning, due to even more out of the ordinary conditions for a gentoo package. A fetch-restrict is far worse since it requires jumping thru the hoops for every upgrade. Yet we do that on a number of packages. Are they all masked? (For all I know they might be as I don't use any such packages.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
