Re: common udpkg and uapt-get functionality
Joey Hess wrote:
>
> Glenn McGrath wrote:
> > The way i see it, a key feature of the new installer is that packaging
> > is much more tightly integrated.
> >
> > There are really 3 levels of abstraction for package managment(ignoring
> > debconf), dpkg-deb, dpkg, and apt-get.
>
> My view is that these three levels are essentially arbitrary and the
> result of the evolution of debian over the years, and I see no need to
> duplicate them. We need to write what we need, not some ideal system,
> and it doesn't have to resemble regular debian package handling at all
> underneath, we're just using regular debian packages because that is
> easy.
>
Not as easy as it should be, i thought another goal was going to be
elimination of base.tar.gz, but we arent allowed to use normal debs to
build the base, we have to isolate ourselves from the main archive to
protect stupid users from forcebly installing uninstallable
packages(e.g. busybox), essentially dumbing down the distribution.
Now we are going to replace base.tgz with a seperate archive of
individual packages, this will save us having to build a base.tgz
everytime one module is changed, but we still need to build seperate
installer modules everytime a package changes, a job that is also done
by the apropriate package maintainer.
Ok. maybe i should just accept this, but i really feel that we are
making a sacrifice here.
> > We are try to make miniture versions of these, im trying to work at the
> > top level to make a retriever
>
> We need a retreiver controller, but it does *not* need to look like apt.
> I'm mostly concerned that we don't know how the retreiver controller is
> supposed to work. Ok, it can download debs and tell udpkg to install
> them. All well and good, but how does it know which debs to download?
> Bear in mind the install process is not going to involve the user
> typing "uapt-get install udeb". What does it do if it can only retreive
> .debs from floppies at first, but the system is later built up to the point
> where it can switch to using the network -- how does it realize this has
> happened and what does it do? What if it has two sources of debs that both
> seem to be euqally good -- how does it figure out which to use? These are
> all questions I don't know the anwsers to yet, and writing a tool that
> looks like apt-get is not going to help much toward answering them.
>
Dendencies, there can be a package named installer.deb (oops i mean
.udeb, im a sarcastic bastard)
that is *always* the first package that is attempted to be installed,
the installer.udeb will have dependencies on core installer modules like
main-menu, udpkg, udebconf, retriever, other non core modules could be
recomended.
A packaging tool that can resolve dependencies (like apt-get does) can
then be automatically started and try and install installer.deb, it will
naturally see that installer.deb depends on all the other packages it
needs, and try and fetch them via the default fetch method that the disk
was setup with.
If the installer detects a network or cd, somewhere that could be a
source of packages, then it must use the default install method to
configure that device. Once the hardware is configured, new Packages.gz
files can be sourced and, the installer can become aware of other
sources of debs. I think at this stage the user may have to specify what
default fetch method to use, or set a priority for each method so it
only uses floppy as a last resort.
That aproach is why ive been working on an apt-get like program, becasue
i was pretty sure we were going to use dependencies to sort things out.
If we arent going to use dependencies, then i will abandon my current
aproach.
Glenn
Reply to: