[gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
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. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
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. -- Thanks, Zac
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
-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. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAk/vNKcACgkQ2ugaI38ACPDDgQD/XhgB1G6rIYXuhR/EnJDLyfgL NKfW6TifMcJr9wHFNooA/2RDkxOSFePAHy81IxGWfjvpb2wNw4b/IzDwK8u4hcAS =Q3Wd -END PGP SIGNATURE-
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
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 :| signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
-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/^/
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
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/,/\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-
>
>
Looks like preserve-libs should be extended to handle this cases:
https://bugs.gentoo.org/show_bug.cgi?id=423087#c5
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
Am Samstag 30 Juni 2012, 13:22:39 schrieb Zac Medico: > 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. As a comparatively simple, user-oriented workaround, since this only happens at downgrades and these should be pretty rare, I have the following suggestion: Make a portage feature that is **on by default**, which causes portage to generate a binpkg of the version to be unmerged, in the case of a downgrade. Rationale: * if you know what you are doing, you can switch this off easily * does not take much space since downgrades are rare * should help our users a lot, whenever someone accidentally or not-knowingly downgrades something critical. Thoughts? Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On Sat, 30 Jun 2012 20:33:35 +0200 "Andreas K. Huettel" wrote: > Am Samstag 30 Juni 2012, 13:22:39 schrieb Zac Medico: > > 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. > > As a comparatively simple, user-oriented workaround, since this only > happens at downgrades and these should be pretty rare, I have the > following suggestion: > > Make a portage feature that is **on by default**, which causes > portage to generate a binpkg of the version to be unmerged, in the > case of a downgrade. > > Rationale: > * if you know what you are doing, you can switch this off easily > * does not take much space since downgrades are rare > * should help our users a lot, whenever someone accidentally or > not-knowingly downgrades something critical. > > Thoughts? > That might be neat, but it would already help if you had to add --allow-downgrades or similar to emerge in case Portage wants to downgrade one or more packages. Besides preventing an accidental downgrade it would raise the awareness of the problem. > Cheers, > Andreas > signature.asc Description: PGP signature
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On 06/30/2012 12:42 PM, Ralph Sennhauser wrote: > That might be neat, but it would already help if you had to add > --allow-downgrades or similar to emerge in case Portage wants to > downgrade one or more packages. > Besides preventing an accidental downgrade it would raise the > awareness of the problem. I think people would just put it in EMERGE_DEFAULT_OPTS and forget about it, since downgrades are a fairly common occurrence, due to changes in version numbering schemes or buggy versions being dropped from the tree. Maybe a RESTRICT="downgrade" metadata setting would help to reduce the noise so that people would be less likely to enable --allow-downgrades by default. -- Thanks, Zac
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On 06/30/2012 11:33 AM, Andreas K. Huettel wrote: > Am Samstag 30 Juni 2012, 13:22:39 schrieb Zac Medico: >> 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. > > As a comparatively simple, user-oriented workaround, since this only happens > at downgrades and these should be pretty rare, I have the following > suggestion: > > Make a portage feature that is **on by default**, which causes portage to > generate a binpkg of the version to be unmerged, in the case of a downgrade. > > Rationale: > * if you know what you are doing, you can switch this off easily > * does not take much space since downgrades are rare > * should help our users a lot, whenever someone accidentally or not-knowingly > downgrades something critical. > > Thoughts? I like that idea. I've filed this bug: https://bugs.gentoo.org/show_bug.cgi?id=424275 -- Thanks, Zac
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
On Sat, 30 Jun 2012 13:01:52 -0700 Zac Medico wrote: > On 06/30/2012 12:42 PM, Ralph Sennhauser wrote: > > That might be neat, but it would already help if you had to add > > --allow-downgrades or similar to emerge in case Portage wants to > > downgrade one or more packages. > > Besides preventing an accidental downgrade it would raise the > > awareness of the problem. > > I think people would just put it in EMERGE_DEFAULT_OPTS and forget > about it, since downgrades are a fairly common occurrence, due to > changes in version numbering schemes or buggy versions being dropped > from the tree. Maybe a RESTRICT="downgrade" metadata setting would > help to reduce the noise so that people would be less likely to > enable --allow-downgrades by default. Nothing wrong with people putting --allow-downgrades into EMERGE_DEFAULT_OPTS if they choose to do so. At least people who'd like this protection could make use of it. Usually both upstream and maintainer put quite a bit of thought into an upgrade path but hardly the other way around. On a system with mixed keywords it's far more common to see downgrades because the unmasked version was removed before stable did catch up than pseudo downgrades because we have no epochs or alike. signature.asc Description: PGP signature
