Re: busybox in main
On Wed Oct 18, 2000 at 07:04:59PM +1100, Glenn McGrath wrote:
> Antti-Juhani Kaijanaho wrote:
> >
> > On 20001018T134523+1100, Glenn McGrath wrote:
> > > A busybox package was previously rejected because it was uninstable on
> > > an existing system.
> >
> > This is not the whole story. The package did not contain several
> > important files required by Debian Policy - including a copyright file.
> > It was my position then, and it is my position now, that this point
> > needs to be discussed in -policy (preferably resulting in an accepted
> > Policy amendment) before such packages can go in main.
> >
>
> The previous package was intended to only be used for the installer, i
> think busybox can be usefull on installed system just to have around
> incase of an emergency.
As packaged, I produced 2 ppackages from busybox: the first package was
designed to only be used as part of the debian-installer. This package was the
cause of contention. Before packaging it up, I asked on debian-boot if policy
compliance was required for this package, or if it should only contain the
binaries. In that discussion, we made the decision that installer specific
packages do not need to be policy compliant. This decision was made by Joey
Hess, project leader for the woody debian-installer. Until I am informed by
the woody debian-installer project leader that something else has been decided,
I will continue to assuming that we are merely waiting for the archive to be
updated to support debian-installer specific packaged with a new "installer"
section. Of course, this all happened in June, so I'm not clear why it takes 4
months to set up a debian-installer archive section...
The second package I produce from busybox is called "busybox-static". It is
100% policy compliant, (with the minor exception that it is intentionally
statically linked). It is designed as a stand alone rescue shell with a ton of
builtin tools. That way if, for example, you hose libc, you can run
"/bin/busybox sh" and use the builtin busybox tools to fix it.
>
> I am proposing it be packaged up so it is lintian clean, i.e. it
> includes copyright file, manpage, other docs, doesnt break dependencies
> etc.
This is a 1 minute change to the package. And would be fine except for
one little thing:
Conflicts: binutils, bsdutils, console-tools, cpio, debianutils, dnsutils, dpkg, fbset, fdflush, \
fileutils, grep, gzip, hostname, modutils, mount, netbase, procps, psmisc, sed, sharutils, \
shellutils, sysklogd, sysvinit, tar, textutils, update, util-linux
This conflicts with dpkg (along with just about everything else), so it would
either need to use update-alternatives (yuck!), or it would have to live under
some other path like installing the link forest under /lib/busybox or
something, or it would have to install only /bin/busybox and ingore the
symlinks. Installing only /bin/busybox dynamically linked on a workstation is
pretty pointless (since the base system installs replacements for everything in
busybox). I think a busybox-static makes sense for a rescue shell (but that
package is already produced by busybox).
I am happy to follow the direction I am given by the debian-installer project
leader for how it should be packaged. So far that involves having busybox
packaged up exactly as requested within days of the request, and 4 months of
nothing happening.
-Erik
--
Erik B. Andersen email: andersee@debian.org
--This message was written using 73% post-consumer electrons--
Reply to: