El sáb, 30-06-2012 a las 13:46 -0400, Ian Stakenvicius escribió:
> -----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/,/
/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-----
>
>
Looks like preserve-libs should be extended to handle this cases:
https://bugs.gentoo.org/show_bug.cgi?id=423087#c5
About trying to prevent downgrades of packages that cause system breakage
