Re: non-installable binaries in main (was Re: busybox_0.45-1_i386.changes REJECTED)
Package: ftp.debian.org
Version: 2 Jul 2000, woody
Antti-Juhani Kaijanaho wrote:
> It'd be best if you could bug ftp.debian.org about it.
Ok, here goes. For woody, the boot-floppies team has plans to rewrite
the Debian installer from the ground up, converting it to use a modular
architecture in the process. The modules here are special Debian
packages, which will be installed into the installer on the fly to
extend its capabilities. They may be downloaded by the installer -- from a
CD, floppies, or the network.
Although they are Debian packages, they will not be policy complient,
and some may not be installable onto a normal Debian system[1]. Despite
these differences, the boot-floppies team has decided to use Debian
packages (instead of tarballs, or something) for a variety of reasons[2].
So, we need a way to upload these packages to the archive, without
getting them put in with all the other debs where a user might stumble
over them. Ideally, they'd be put in main/disks-*, while their sources
could go in there, or perhaps better, go into main/source/<something>.
This requires marking the boot-floppies debs in some way so they can be
picked out. We don't really care how; whatever works. One idea I've had
is that we could name them with a different extention than ".deb"
(".dab" or ".dib", perhaps?) and list them as "hyhand" files in the
.changes file.
One final alternative would be to add a new section, like
main/binary-*/installer, and put them in there. If this were done, we
would have to make sure they can be safely installed onto a normal Debian
system. This is my least favorite option.
The first of these packages -- a .deb of busybox[3] -- is already built,
and was rejected because there was no sane place to put it yet.
--
see shy jo, boot-floppies team leader for woody
[1] Wasting space on the installers ram disk for stuff like
man pages and copyright files is not a good idea.
[2] We want to be able to use dependancies; there is lots of useful
infrastructure for dealing with debs, and so on.
[3] Miniature versions of most standard unix tools.
Reply to: