[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Which version of dpkg before library upgrade to slink?



Hi,

On 9 Dec 1998 john@dhh.gt.org wrote:

> Joost writes:
> > If you are daring and gifted with bandwith just do a dist-upgrade with
> > apt.  It should work well and if it doesn't, that's probably a reason to
> > postpone the release of slink until hamm can be smoothly upgraded
> > automatically using apt.
> 
> I don't have the bandwidth for a dist-upgrade, but I just tried to upgrade
> to libc6 2.0.7u-7.1 from libc6 2.0.7u-4 with apt-get.
> 
>   And broke bash.

I'm sorry, if that makes you feel better about it ;-)

Hey, this sounds Not Good.  I don't know about the exact situation before,
during and after, but if a missing Dependens: of Conflicts: causes major
breakage during upgrades, that should be cause for a critical bugreport
against the package(s) that are failing to provide the proper dependency
information to dpkg (and apt.)  Could you please check what happened
exactly and what package is at fault?

> I'm fairly sure that the version of bash that broke was the one in hamm
> (sorry I didn't think to take careful notes...).  I was able to recover by
> linking sh to ash, downgrading to hamm versions of dpkg and libc6, and
> starting over.  Everything is working now.  "Segmentation fault" is not
> something I like to see during a libc6 install.  If it is worth doing I'll
> try to figure out a safe way to test this.

IMHO it is very much worth so.  But hey, watch out listening to my advice
;-)

> I take it back.  Somewhere in there netstd got "upgraded", and now telnet
> is gone.

Join the club of complainers.  No, better still, figure out a general
method to solve issues like the splitting of telnet and telnetd.  

The best approach that I can come up with is to have an intermediate
package netstd that provides both future packages, followed by a version
that no longer provides both, so that when the intermediate package is
upgraded, it will automatically cause the new package to be "upgraded"
from a virtual package to the first real version.  I'm not an expert at
dependency wizardry, so don't shoot me if the above sounds overly
ignor^H^H^H^H^Henthousiastic.

That's still far from perfect, but the best I can come up with.

> Ok, I got it, but these splits are going to cause trouble...

Hmm, yeah, probably :-(

Cheers,


Joost


Reply to: