FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-30-2012, 11:07 AM
Pacho Ramos
 
Default 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.
 
Old 06-30-2012, 11:22 AM
Zac Medico
 
Default 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
 
Old 06-30-2012, 03:16 PM
Mike Frysinger
 
Default 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
 
Old 06-30-2012, 05:17 PM
Ian Stakenvicius
 
Default 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-----
 
Old 06-30-2012, 05:30 PM
Pacho Ramos
 
Default 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 :|
 
Old 06-30-2012, 05:46 PM
Ian Stakenvicius
 
Default 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/,/
/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-----
 
Old 06-30-2012, 06:05 PM
Pacho Ramos
 
Default 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/,/
/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
 
Old 06-30-2012, 06:33 PM
"Andreas K. Huettel"
 
Default 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
dilfridge@gentoo.org
http://www.akhuettel.de/
 
Old 06-30-2012, 07:42 PM
Ralph Sennhauser
 
Default About trying to prevent downgrades of packages that cause system breakage

On Sat, 30 Jun 2012 20:33:35 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> 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
>
 
Old 06-30-2012, 08:01 PM
Zac Medico
 
Default 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
 

Thread Tools




All times are GMT. The time now is 01:03 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org