Re: Upgrade docs and Release Notes (was Re: Starting second test cycle)
On Thu, 1 Jun 2000, Ben Collins wrote:
> On Fri, Jun 02, 2000 at 12:07:58AM +0200, J.A. Bezemer wrote:
> >
> > On Thu, 1 Jun 2000, Ben Collins wrote:
> >
> > > >
> > > > BTW, it just crossed my mind that a potato/sparc-compiled static apt might
> > > > just work perfectly ONCE you have a 2.2.x kernel. Procedures would then become
> > > > very easy:
> > >
> > > Yes, but not everyone reads the docs on upgrades.
> >
> > Indeed. However, in this case the problem is likely to solve itself, since
> > no-one will even know about the static apt/dpkg _unless_ they read the docs.
> > And a DO_NOT_INSTALL_THESE.txt along with the .debs should do the rest.
> > Debian sysadmins usually are not _that_ stupid ;-)
>
> Heh, you're very trusting of people's ability to read an entire document.
;-) Well, I do have a vague suspicion that the release-notes are going to be
the most-read doc in potato. Upgrading isn't trivial. You can of course also
name the packages like apt_0.3.19_sparc_I_WILL_BREAK_YOUR_SYSTEM.deb
You must be _really_ brave to install that without further reading ;-)
> > > > - compile & install 2.2.x kernel
> > >
> > > "install the kernel deb from potato"
> >
> > (unless you need some special options ;-)
>
> The sparc kernels have all the standard options compiled in.
>
> > > > - install static apt/dpkg if using CDs
> > > > - <see other arches>
> > >
> > > "see general upgrade procedure"
> > >
> > > > Will this work? Why not? (Apart from the fact that the preinst of dpkg/apt
> > > > don't check for a 2.2.x kernel (which, if needed, should be solvable easily))
> > >
> > > That's the kicker, and it is not so easily solvable without copying over
> > > the ugly hacks I have in libc6's preinst. Which I would not even want in
> > > either of these packages.
> >
> > Are they really so ugly? (if uname -r != 2.2.* then "exit -1"? or something
> > with /proc/version?) And anyway, these are only non-mainstream temporary pkgs
> > (i.e. no need to get these hacks in the "regular" apt/dpkg source; the
> > "staticness" hacks aren't either). I don't see a big problem.
>
> Ok, so we distribute binaries without source on our official CD's!? Come
> on, this is absurd.
No, we don't. The "hacks" for static apt/dpkg are in upgrade-i386/src/, read
the COMPILING.txt there. Two more sparc-only replacement preinsts wouldn't
hurt a bit.
> > > > Also to Josip: I know you can upgrade by mounting each CD consequtively etc.
> > > > That's the way 2.0->2.1 was done. You can also upgrade by
> > > > dpkg -i /cdrom/dists/potato/main/binary-i386/xxx/yyy.deb for each and every
> > > > package, which is just slightly more horrible.
> > >
> > > No, you could simply do apt-cdrom on the first CD *only*, then
> > >
> > > "apt-get install apt dpkg"
> > >
> > > This would get you that far, and then you would have the new packages,
> > > wihtout a lot of fuss, and run apt-cdrom on the other 2 cdrom's, and run
> > > "apt-get dist-upgrade".
> >
> > Yeah, I've thought of that, too. Only it doesn't work on anything < 2.1r4
> > (2.1r0's apt doesn't have apt-cdrom), so you'd have to fetch & (manually!)
> > install "half-new" slink versions first anyway. Also apt 0.3.19 fixes a random
> > (timing-related) deadlock thing in the CD handling, so if you're out of luck,
> > "apt-get install" from CDs "won't work as expected". (Never happened to me,
> > but I've seen several reports.)
>
> For sparc that is fine. I'm willing to tell people to make sure they have
> the latest slink apt/dpkg before proceeding and use this method than to
> compile a static apt/dpkg and hack together some preinst checks. As for
> the apt problem, it is _only_ eveident when some odd sequence of
> _multiple_ CD's are involved in upgrades. This wont happen if you only do
> apt-cdrom on CD #1, and only install apt and dpkg. I know, I've tested
> this much before.
Excellent! So that's the preferred way of upgrading sparc. Good. If it hasn't
been done already (don't have CVS at the moment) I'll add it to the
release-notes patch I intend work on tomorrow.
Regards,
Anne Bezemer
Reply to: