Re: Deep freeze - was the libc6 problem solved?
Brandon Mitchell <bhmit1@CS.WM.EDU> writes:
> I never received a good definition of the problem and fix. If someone is
> willing to determine which packages are broken and describe exactly what
> packages a developer needs to upgrade in order for a proper recompile to
> occur, I'd be glad to send this mailing (one message per developer).
I have done a lengthy investigation of what is going on, and basically
it all comes down to a lengthy but inconclusive debate in
debian-devel. Seemingly, it all has to do with some ex-problem known
as the "register_frame_info" problem. I don't know what the
register_frame_info problem was, but I know that past tense is
8 Dec 1998, Ray Dassen:
| Current frozen does _not_ suffer from the __register_frame_info
| problem in any way anymore, to the best of my knowledge.
However, it seems to have left a rather annoying legacy:
8 Dec 1998, Stephane Bortzmeyer:
| MANY packages still depend on libc6 >= 2.0.7u (the slink version) which
| prevents them (in an unecessary way) to run on hamm. Developers should
| recompile them against the latest libc6-dev which no longer uses
| incorrect dependencies (which were added because of the
| register_frame_info problem).
| It is just recompiling but it has to be done.
The bad consequence of this legacy seems to be
(small consequence) Hamm users using some slink packages will need to
upgrade their libc6 just to satisfy a spurious dependency; this is
offensive to many people's sense of order.
(big consequence) Hamm users who upgrade with dselect, not using apt
(a situation many would be in, since apt wasn't in hamm) will find
their install fails first time round. The fix is simply to try again,
but it's rather ugly and doesn't help Debian shake its reputation of
difficulty of use.
HOWEVER, "MANY packages" means 486 of them - I just downloaded the
latest Packages.gz and counted ("zcat Packages.gz | grep 2.0.7u | wc").
All of them would have to be recompiled, and because of the way the
Debian versioning system works, they would have to be recompiled for
all platforms. And cross-compilation has been found to be basically
unworkable, meaning all 486 (including many rather big ones, like much
of X) would have to be recompiled on their native platform. This is
OK for slink-alpha, but starts to imply that we'll be lucky to get
slink-m68k any time this millenium. Since it's felt by some that
slink should release on all platforms at once, this would put back the
whole of slink for a long time.
That's what I've found out. AFAICT there are arguments for all sides
here, but I don't think I understand all the issues to know that for
sure. The mood seems to be against insisting on fixing it across the
board, but it's inconclusive and some people have been converted in
favour of the recompile.
I care only because I want to buy a Slink gold CD, but I don't want to
be prompted to download 486 packages in order to change the "Depends:"
line, so either seeing this problem fixed or knowing that it won't be
for Slink suits my purposes. I therefore hope that someone can make a
decision and say "this is what has been decided" so we can progress.
As far as I can tell, the whole debate kind of fizzled out over a
month ago, and the dependencies are still there, so we could take that
as a concensus decision to ignore the problem. Or I could turn this
message into mail to feed to my cunning script and explain to everyone
why we're asking for a rebuild. I'm a great believer in concensus but
sometimes I wish for a decision from On High.
The irony is, of course, that part of the reason people were against
the rebuild was that they feared it would push the slink release into
1999. Perhaps if they'd just started when the debate started they
would have finished by now...
\/ o\ firstname.lastname@example.org http://www.hedonism.demon.co.uk/paul/ \ /
/\__/ Paul Crowley Upgrade your legacy NT machines to Linux /~\
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org