Re: packages (was Re: [woody,debinst] `parted' and non-DOS compatible partitioning schemes)
On Sat, 17 Jun 2000, Joey Hess wrote:
<...>
> These wouldn't be .deb's that are policy complient, or that you'd want
> to install onto a real debian system. (They would in fact, probably have
> dependancies to prevent that.)
Policy is what you people make it, since .debs have never been used in
this kind of application before (task-*.deb packages lean in that
direction) it is reasonable to expect some new policy to arise out of
the effort.
It would be very confusing to have .debs that could not be installed
onto an existing Debian system. The boot-floppies .deb is not useful to
the average user, but it can still be installed; debinst .debs would be
installed for the same reasons that someone would want to install the
boot-floppies .deb.
> But I can see lots of benefits to using
> debs. We know how to build them. They're simple to extract, requiring
> only 3 programs. We have structures in place to manage them. They even
> give us dependancies if we find we need such a thing.
I would expect dependencies to be crucial in a modular .deb based
installation system. e.g., the installer module would depend on a
partitioner module being configured, which would depend on at least one
HD module being installed and configured, which may in turn depend on a
controller module (if the HD module is for an SCSI drive).
> I can't see any real disadvantages over a plain tarball, except a tad
> more size.
I think the advantages of having a consistent UI for administering a
Debian system, and the existing infrastructure geared towards handling
.debs, far outweighs both the additional overhead required and the
extra difficulty in defining the new installation system.
later,
Bruce
Reply to: