Re: autoup.sh & considerations on bail-out scripts
On Thu, 12 Feb 1998, Raul Miller wrote:
> > > Is there any where we can wedge in an upgraded libc5 dpkg?
> >
> > AFAIK, there is no way to guarantee that users will have a new dpkg,
> > and what's more the maintainers of it seem to have taken a vacation in
> > the Bermuda Triangle, so we will probably have to wait for any
> > substantive changes (although non maintainer releases are slowly
> > taking place, I guess:-)
>
> We can put a dpkg in the distribution, but there's the issue of
> how do you upgrade it again to complete the upgrade. OR, maybe
> we need to resign ourselves to living with a libc5 version of
> dpkg for hamm (which implies another major debian release
> after a very short time).
that's part of what autoup.sh does...automatically upgrades everything
essential for the upgrade to hamm, including dpkg.
it may not be the most elegant solution but it works.
> Any change to dpkg we can cast as a shell (or whatever) wrapper around
> the existing functionality of dpkg gets around the lack of documented
> design interfaces for its internals.
>
> We know that dpkg as it currently stands can't do the hamm upgrade.
>
> We know that we need to do this hamm upgrade.
>
> One option is to just throw up our hands and say "we goofed, you're
> going to have to work around the limitations of our package management
> system". Another option is to fix our package management system.
i think that's an exaggerated way of looking at the problem. dpkg just
installs whatever it's told to, in the order it's told to do it.
the default 'mounted' -iGROEB method is showing it's age, but dselect
allows for alternate install methods. what this means is that we need
to improve the existing methods.
we currently have 7 install methods (cdrom, nfs, harddisk, mounted,
mountable, floppy, ftp). we really only need 3.
1. mountable does everything that cdrom, nfs, harddisk, and mounted
does and more. it is a general solution - if you can mount the file
system then dpkg-mountable can install from it.
it has two drawbacks: (a) inability to handle pre-dependancies, and
(b) the bug which requires you to run Update again after any error.
Apart from these, it is in every way superior to the other similar
methods. Both of these problems are fixable.
2. the floppy method is probably a special case and needs to be handled
separately.
3. an experimental version of dpkg-ftp can already handle ftp (and http
too i believe) installs with at least some support for pkg-order.
The best thing to do IMO, is to make mountable and dpkg-ftp the standard
methods, and do whatever is necessary to bring them up to scratch.
both are perl script extensions to dpkg/dselect. both should be fairly
easy to fix up...dpkg-ftp is being actively maintained and is almost
ready right now, which leaves only dpkg-mountable to be worked on.
dpkg-mountable works extremely well but doesn't yet understand
pre-dependancies...it also needs support for pkg-order (which would
solve the pre-dependancy problem).
pkg-order is cool and solves many of the current technical (but not user
interface :-) problems with dpkg and dselect.
unfortunately, we're still going to need my autoup.sh script (or
something very similar) to do the upgrade from bo to hamm - any
improvements we make to dpkg methods wont be available on the target
system until after the autoup stage of the upgrade has completed.
> But, something has to give.
>
> Currently, I'm leaning in the direction of a "pkg-order" wrapper for
> dpkg.
that's what dpkg-mountable and dpkg-ftp can provide.
craig
--
craig sanders
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: