Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/06/12 01:30 PM, Pacho Ramos wrote:
> El sáb, 30-06-2012 a las 13:17 -0400, Ian Stakenvicius escribió:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> On 30/06/12 11:16 AM, Mike Frysinger wrote:
>>> On Saturday 30 June 2012 07:22:39 Zac Medico wrote:
>>>> On 06/30/2012 04:07 AM, Pacho Ramos wrote:
>>>>> I would like to discuss a bit more issues like:
>>>>> https://bugs.gentoo.org/show_bug.cgi?id=423087
>>>>>
>>>>> Even if there are "a lot" of packages that can cause this
>>>>> breakage when downgraded, I think it should be prevented
>>>>> and package managers shouldn't try to downgrade this kind
>>>>> of packages as they will later cause a total breakage.
>>>>> People is not supposed to know that downgrading some
>>>>> package system will, for example, have an unusable gcc.
>>>>
>>>> It seems like a die in pkg_pretend would serve pretty well.
>>>
>>> doing it on a per-ebuild basis doesn't make much sense.  a
>>> simple version compare (like we do in glibc as an exception to
>>> this rule because of its much wider implication) is incorrect:
>>> the new version might not introduce any new symbols compared to
>>> the old one, and even if it has, other packages might not have
>>> been linked against the new symbols. -mike
>>
>> Instead of preventing downgrade wouldn't it make more sense to
>> figure out a way to force a rebuild on @system or @toolchain or
>> whatever bits are broken as soon as the downgrade occurs, rather
>> than just making it a one-way ticket?  If we could sort this out
>> (and sub-slots may help with this, but probably we'll need some
>> extra work too) then we could probably support switching from
>> ~arch to arch at a whim..  Not necessarily a bad goal.
>>
>
> The problem is that, in this kind of breakage, gcc breaks as soon
> as zlib is downgraded and, then, user cannot compile anything,
> needing to manually find missing zlib lib from any other
> distributions binaries, put it in the system and re-emerge zlib :|
>

..but preserved-libs would keep that from happening wouldn't it?  ie,
the lib itself would stick around until gcc isn't using it anymore...

so it'd just be a matter of an interim issue until preserved-libs is
in stable portage ...  and i'm guessing something that would suffice
here is a blockage on downgrades of anything belonging to the contents
of /var/db/edb/{sys-devel/gcc,sys-libs/glibc}-[0-9]*/NEEDED ?

(apologies for the bad hack:)

cat /var/db/pkg/{sys-devel/gcc,sys-libs/glibc}-[0-9]*/NEEDED \
  |sed -e 's#^/[^ ]* ##' |sed -e "s/,/\n/g" |sort -u \
  |xargs equery b |awk '{print $1}' |sort -u \
  |sed 's/^/</'

^^^ that's your build-preserving package.mask , yes?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/vO4gACgkQ2ugaI38ACPBUvwEApQAljVOj492q2/bhttriqWgz
iu8FZdsh1EHMeYaHxi0A/iZNY28W9NT5ynO6B42CAxpYpWym2SIc4JflTu/7IK1h
=3pcd
-----END PGP SIGNATURE-----