-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/12/12 03:35 AM, Michał Górny wrote: > 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. Users won't even realize they have a known >>> flaw, because they had to unmask the package just to install >>> it. I think there is a big difference between "bundles libs >>> and therefore might have a security issue" and "has a known >>> security issue." >> >> Very good point. >> >> Being a (somewhat pragmatic) security emphasis person by default, >> as well as a freedomware person, I had been leaning toward the >> "mask it and let the user decide" viewpoint, but this question >> changed my mind entirely. >> >> 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... >
... a die in pkg_pretend is "fails to be permitted to emerge", not "fails to build". And this would be essentially a p.mask but without it using the portage p.mask (and its various connotations). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlC7qWsACgkQ2ugaI38ACPCh9gEAsBPiECtphA9/H33ucTrfHpQd 2j0dNDOxVxsX+BjOXqQA/2PS3sMy1X8G8+pvj6p7lRsbm0a8IuT1jWNE0pu5TrfC =Z0nu -----END PGP SIGNATURE-----
