[gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Duncan <1i5t5.duncan@cox.net>]

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.duncan@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