Re: busybox in main
Erik Andersen <andersen@codepoet.org> writes:
> 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...
Because (a) it requires an archive change, which means a dinstall
change, which also means potential repercussions in the bug tracking
system, and (b) because the section as conceived, violates Debian's
own Policy on what "main" means.
> 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.
Well, my word has some weight too, now, speaking as the boot-floppies
maintainer, since it seems that boot-floppies may well be the standard
installation system for woody. (And I'm less happy about this than
anyone.)
My argument resolves around the fact that you guys have come up with a
plan based on your guess of what the debian-installer needs are. To
that end, you have come up with a system which requires a bit of
radically rehandling, at least from the archive master's point of
view. Moreover, shipping packages as you do (without copyright file,
for instance) pretty much radically breaks down what it means for a
package to be in main.
Or you are asking for a new section which is not "main" or contrib or
non-free at all, which is even more of a hassle.
In short, you are challenging the Debian policy and the current
practices of archive maintenance etc. That is why it is 4 months with
no action.
I am not trying to pre-empt Joey Hess, but I think we all need to step
back and adopt a more reasonable busybox pkg which will (a) not
challenge Debian's notion of 'main'; (b) will not require policy
changes; and (c) will meet the needs of boot-floppies as well as
debian-installer. For the building the root disk and such, I need
busybox in main.
I re-iterate my suggestion. Simply provide the dynamically linked
busybox package in a more unobtrusive way which conforms to baseline
policy. E.g., put busybox executable in /usr/lib/busybox/busybox, and
provide the mklinks.sh script (or whatever) under /usr/lib/busybox or
/usr/share/busybox (since it's a shell script I guess) such that as
part of my root disk building routines in boot-floppies I can call
that script in an automated fashion (and for bonus points, retain some
control on what it creates).
Moreover, include the *baseline* stuff required such as changelogs and
copyright, etc. I can remove this for space if I need to during the
rootdisk production; I assume udpkg will be able to have similar
functionality.
For the purposes of debian-installer, which are not even yet all that
clear, assuming postinst scripts are called at all, you could perhaps
provide in postinst some sort of check for whether we're being
installed by udpkg and automatically make the requisitic links.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: