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

Mike Frysinger posted on Sat, 30 Jun 2012 11:16:51 -0400 as excerpted:

> 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.

glibc was the example that popped up in my mind as well. Two comments:

* Please make sure there's an override in case the user needs it, like
glibc has.

* Glibc's override is unfortunately broken in one specific case: binpkgs.
The binpkg must have been built with the override (I_KNOW_WHAT_IM_DOING=1
or whatever) set, or it won't work.

I found this out the hard way, when I upgraded a glibc and immediately
found it broken for something or other. I hadn't rebuilt anything else
yet (I try to do glibc upgrades by themselves, /because/ of their
critical nature), so everything was still built against the old glibc and
there would have been no breakage. Since I run FEATURES=buildpkg by
default, I thought "no problem, I'll just emerge the old binpkg."
WRONG! Because it wasn't built with the override variable set, it
wouldn't let me downgrade using the binpkg!

But whatever breakage I had wasn't letting me rebuild, either!

Which is exactly why I have multiple bootable rootfs (with everything
portage installs on it) setup, so I can boot into a bakup root if my
normal working one gets hosed, somehow. So I just booted into it,
mounted my normal working rootfs, set ROOT= to point to it, and went from
there.

It would be MUCH easier if a glibc binpkg downgrade could look only at
the existing portage environment for that variable, not check the one in
the binpkg!

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On 07/01/2012 12:20 AM, Duncan wrote:
> * Glibc's override is unfortunately broken in one specific case: binpkgs.
> The binpkg must have been built with the override (I_KNOW_WHAT_IM_DOING=1
> or whatever) set, or it won't work.

You can always override environment variables (even for binary/installed
packages) by setting them in /etc/portage/bashrc (or in a per-package
bashrc in /etc/portage/env/$CATEGORY/$PN,$PF...).
--
Thanks,
Zac

On Sat, 30 Jun 2012 13:01:52 -0700
Zac Medico <zmedico@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.