[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

non-installable binaries in main (was Re: busybox_0.45-1_i386.changes REJECTED)



A recent thread on debian-boot concerns wether busybox should be allowed
into woody as a seperate package.
Busybox is a vital component of the installer but would NOT be useable
or installable post install.

The reason for rejection
On Sat Jul 01, 2000 at 11:27:31AM -0400, Antti-Juhani Kaijanaho wrote:
> This package violates policy in several ways:
>   - first of all, the busybox binary package does not include 
>     a copyright file, a changelog file or - indeed - a
>     /usr/[share/]doc/ directory!
> 
>   - second of all, 
> E: busybox: symlink-should-be-relative bin/head /bin/busybox
> [...]
> 
>   - third of all, I am not sure if it is a good idea to
>     include a package in the distribution that cannot be
>     installed into a system without breaking that system
>     (this package conflicts with many essential packages)
>     You should definitely bring this issue up on -devel or
>     -policy before reuploading (btw, I cannot find an ITP
>     for this package...) 
> 
> If you don't understand why your files were rejected, or if the
> override file requires editing, reply to this email.
> 
> Your rejected files are in incoming/REJECT/.  (Some may also be in
> incoming/ if your .changes file was unparsable.)  If only some of the
> files need to repaired, you may move any good files back to incoming/.
> Please remove any bad files from incoming/REJECT/.

and the latest post.
Antti-Juhani Kaijanaho wrote:
> 
> > If it can't be installed, and it is documented as such in the
> > package description, then I see nothing of how it affects the distribution
> > as a whole.
> 
> I see introducing uninstallable packages deliberately as affecting the
> distribution as a whole, and I maintain that it needs to be discussed
> as such a matter.
> 
> > The only other alternative is to provide a source .deb instead
> > of a binary package.
> 
> Why does it *have* to be a .deb?
> 
> (And yes, a source deb would probably be less intrusive.)
> 

Firstly i understand why concerns were raised, but my opinion is that if
you look at the big picture there is nothing to be concered about.

>From the installers point of view and the distribution as a whole it is
better is the installer is integrated with the distribution as much as
possible.  deb is a perfect choice for components of the installer just
as it is for other binary packages. Why shouldnt the advanteges of
packages be available to the installer ?

Creating the installer by drawing from a pool of existing conveniently
lcoated packages is better than downloading/creating a big tarball every
now and again.
Im sure you can see why the installer team would want installer
components in main.

The only drawback of having installer components located in main is that
some components such as busybox are not intended to be useable post
installation.

It is indisputable that the installer as a whole is very valuable and
has to go somewhere

Possible places for installer components 

1) Amoungst source packages.
I think it would be wrong to treat a binary package as a source deb as
suggested previously, a binary package is a binary package, if it cant
be treated as such then there is something wrong.

2) In there own seperate area. (e.g. disks-i386)
Currently the installer has its own area, the vast majority of the
installer (e.g. base.tgz) is extracted from packages in main, the
disks-i386 directory is now 100MB which covers all the different
flavours of installs for this architecture only.
Having a seperate area means it doesnt have to be mirrored, but 99% of
the isntaller is extracted from main anyway, so if your mirroring main
segregating the installer isnt going to save any bandwidth or space.

3) In main 
This IMHO is the only logical choice, even though a component isnt
directly useable its a vital component of a useable program, the
installer has to be created somewhere, an analogy could be made between
non-installable binaries and libraries.
Distributing installer components seperatly could mean packages could be
released independently, rather than generating 100MB of files every time
a change is required.

The package in question (busybox) is probably around 500KBytes or so,
there could be more non-installable binary packages required for the
woody installer (its a bit early to say) but they would also most likely
be small.

If package pools gets implemented for woody then this is less of an
issue.


Does anyone have any objections to installer components that are NOT
usable post install being placed in main? 

Thanks

Glenn McGrath



Reply to: