Re: The logical extension of the 'installer packages' concept
Jules Bean <jmlb2@hermes.cam.ac.uk> wrote:
> For some packages, we need two different 'incarnations' of the package.
> Say, 'bgs-vol-1_1.0-1.deb' and 'bgs-vol-1-inst_1.0-1.deb'. And
> bgs-vol-1-inst, when installed, goes and, somehow, fetches the actual
> data, and registers it with the dpkg database, so that bgs-vol-1 is in
> fact now installed.
>
> Now, in fact, bgs-vol-1-inst doesn't actually need to be a package,
> since it doesn't need to persist. The situation immediately after
> installing bgs-vol-1-inst should be exactly the same as the situation
> immediately after installing bgs-vol-1, only the method of acquisition
> should differ. However, I think it would be breaking a well-established
> invariant of packages if two packages of the same name and version could
> differ in any way.
>
> What I'm saying is that we could usefully have a standardised approach
> to building installer packages, which generalises so that some data can
> exist either as a full package on a mirror, or as an installer package,
> more-or-less transparently to the user - but not to the mirror
> maintainer!
I have been thinking about this for a while. We have a number of different
styles of package in debian at the moment, and they are all handled in
different ways. We have two kinds of traditional source package, native debian
source packages and upstream+patch packages that produces one or more binary
packages when built. There are the binary packages that are actually source
packages like pine and qmail that produce binary packages. There are two
types of installer package, the xanim-modules installer package downloads the
modules itself and installs them, where as the realplayer package leaves the
downloading up to the user, but installs the package itself.
I would suggest that apt could be redesigned to manage the download of the
47Mb GMT data and the xanim-modules in a way that Jules discribes. The problem
we have with Realplayer is that we can get the addresses of the mirrors, but
they are updated often and Joey Hess does not want to update the package every
time a mirror location changes.
Another similar way of reducing bloat would to stop supplying the upstream
source on debian mirrors, just provide a list of mirrors where it can be found
and have netselect built into apt, so it can find the best mirror and download
the code. This would require perfectly pristine source, without the
.orig.tar.gz ending change and the directory name not set the debian way.
Imagine a site like src.doc.ic.ac.uk which mirrors a lot of stuff including
debian, it probably has all the non-native debian source packages held twice,
is this really needed.
What I think that I am trying to say is that that all packages could be
reduced to binary and source packages. Binary packages are as they have always
been, and most source packages are the same as well, but add a flag saying that
autobuilders should not build certian binary packages. It would then be
possible to have source packages for programs like pine, qmail, realplayer,
xanim-modules and the 47Mb gmt package. When apt-console or dselect does a
listing of available binary packages, it can list the ones that have source
but no binary, when you select to install them, the source is downloaded,
source depends are handled and the package is built.
--
I consume, therefore I am
Reply to: