Re: common udpkg and uapt-get functionality
Randolph Chung wrote:
>
> > Ive been working on a uapt-get.
> >
> > Currently status is that it can process //etc/apt/source.list and fetch
> > the Packages.gz and Source.gz files by calling wget, then to merge the
> > package files i am calling "dpkg --merge-avail <package name>" to
> > generate a correct //var/lib/dpkg/available file.
>
> Glenn, while there may certain a place for a "uapt-get" type
> application, there are still MANY TODO items in the d-i list needed to
> get a basic system working. Would you be interested in working on one of
> those instead for now?
>
> randolph
Well, when i say im working on uapt-get, i consider that to be a
retriever, which will need to be a core component so really does need to
be done.
I think we (or maybe just I) need to coordinate our efforts better, ive
been feeling like a 5th wheel of late.
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.
dpkg-deb should do low level work, extracting data and control info from
debs (using tar, gz, ar)
dpkg should be managing packages locally, actually installing files,
updateing status and available files etc, it shpuld call dpkg-deb for
extracting debs.
apt-get should be feeding dpkg with packages that its obtains from
various means, and call dpkg to handle them locally.
We are try to make miniture versions of these, im trying to work at the
top level to make a retriever, but finding that there could be extra
lower level stuff that could help me. I have two choices, 1) fix up the
lower level to what i think they should be, or 2) start from scratch and
implement functionality that belongs in lower level in the fetcher.
Doing 1) will result in a better product.
In terms of integrating these 3 levels of package management, i really
think we should make shared libraries for each level so the
functionality can be shared much easier, i cant think of any reason not
to use libraries, i dont think they have much of a space overhead. If we
dont use libraries the only other way to share functionality is by
calling lower levels via system() calls which use the shell, or exec
calls(?), which both seem much harder to keep track of than libraries.
If all core components were built as shared libraries then the installer
could be built as an init program with minimal overheads.
Modularity is very important to non core components, but its more
efficient to have all core components linked together.
If think the retriever is important becasue its core and we dont have
one yet, the other core components are making progress arent they?
Glenn
Reply to: