Re: glibc recompiling was Re: libc resolver problem solved (critical bug)
Dale Scheetz <email@example.com> writes:
> The conflicts route is OK, but that list is growing every release, and
> will never "go away", so managing this problem with a conflicts is
> relatively undesirable. I am willing to add a conflicts with the specific
> dpkg version involved, but not much more than that, as that is a
> sufficient fix to allow "disaster recovery" from the previous libc
> Is this satisfactory?
It looks the right solution to me, just uploading a new libc and dpkg
is the way to go.
A minor tought: maybe a Pre-depends on the new dpkg version may be
better than a Conflicts with the bad one (or do you need both?), that
way people may upgrade both in the same dpkg run because I think dpkg
is able to order upgrade according to Pre-Depends. Just adding a
conflicts can cause libc to fail to upgrade in a first run, and
requires a second.
Besides if you are afraid to be stuck forever with conflicts and
pre-depends, I would say these particular ones could maybe go away in
the future, maybe around or after potato release, as I do not think we
have to provide forever clean upgrades path for every intermediate
state of the unstable archive, (only for packages that went into