Re: glibc recompiling was Re: libc resolver problem solved (critical bug)
On Thu, 19 Nov 1998, J.H.M. Dassen (Ray) wrote:
> On Thu, Nov 19, 1998 at 10:36:26 -0500, Dale Scheetz wrote:
> > So, what is wrong with recompiling dpkg against the new library? The old
> > library is broken, so we have to move, and forward is the only logical
> > direction.
>
> There's nothing inherently wrong with it. But we have to be _very_ sure
> there's no upgrade scenario for users which will break dpkg and apt for them.
We are currently in a pre-release freeze. None of the development work
done here is more important than the final product. Requiring "smooth"
upgrade paths for ever point release of a package "on the road to a
release" is not reasonable. Our goal is to produce a release that can
upgrade any previous release, not one that can upgrade very broken package
produced between the last and this release.
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
release.
Is this satisfactory?
>
> The best way to do that perhaps is for you to build the new libc6 (including
> Conflicts: info for the affected dpkg and apt) and NMUs of dpkg and apt, and
> make sure they're installed in the same archive upgrade run.
>
The conflicts: make this unnnecessary, as you can't upgrade libc until you
upgrade (or downgrade) dpkg.
> > > - fork of a libc6-fixed package which installs in a different location than
> > > /lib (e.g. /lib/fixed), and provide a matching libc6-dev.
> > > - Identify which other packages besides dpkg and apt that are likely to be
> > > essential for many people have versions that depend on
> > > (un)register_frame_info symbols, and recompile all of them.
> > > - Then fix the regular "libc6" package, and make it have explicit
> > > Conflicts: with the problematic versions.
> > >
> > The first item is not necessary, very difficult, and likely to deliver its
> > own set of problems.
>
> Why? Just mv it in the "binary" target, and put a different link to it in
> the -dev package. The idea is that it's not going to be used to run binaries
> against, only to build fixed binaries (which will run with the broken libc
> too).
The "just mv" and "put a different link" activities are fraught with
potential mistakes and problems. We could just as easily break something
more important (if there is any such thing) and spend unnecessary time
trying to figure out just what I did wrong. I just don't see any point
in venturing into unknown territory, when the current bog is so well
mapped out. The path out is pretty obvious to me, and it doesn't involve
any "dredging and filling" the way you want to do it.
Luck,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Reply to: