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

2012-07-07 Thread Ralph Sennhauser
On Sat, 30 Jun 2012 13:01:52 -0700
Zac Medico zmed...@gentoo.org 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


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

2012-06-30 Thread 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.
-- 
Thanks,
Zac




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

2012-06-30 Thread Mike Frysinger
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

2012-06-30 Thread Ian Stakenvicius
-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

2012-06-30 Thread Pacho Ramos
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

2012-06-30 Thread 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-



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

2012-06-30 Thread Pacho Ramos
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

2012-06-30 Thread Andreas K. Huettel
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

2012-06-30 Thread Ralph Sennhauser
On Sat, 30 Jun 2012 20:33:35 +0200
Andreas K. Huettel dilfri...@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
 


signature.asc
Description: PGP signature


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

2012-06-30 Thread Zac Medico
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

2012-06-30 Thread Zac Medico
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