Re: packages (was Re: [woody,debinst] `parted' and non-DOS compatible partitioning schemes)

[Bruce Sass <bsass@freenet.edmonton.ab.ca>]

On Sun, 18 Jun 2000, Joey Hess wrote:
> Bruce Sass wrote:
> > 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.
> 
> Ok, but we'd have to make sure they don't get in the way of the real
> system, then.

Or are fully integrated into the real system.  It seems reasonable to me
that a user wanting to install a new piece of hardware should be able to
select it the same way they select a piece of software, ditto for system
configuration.

> > 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).
> 
> Hm, that's a good idea. Presumes that modules are configured in their
> preinst or earlier, though.

Thanks.  Pre-depends stuff, eh.  Hmmm, this could be a good thing... 
Karl started the thread by expressing a desire to get rid of the serial
nature of the current UI, this adds the problem of translating what the
user wants to do into the mostly linear installation procedure; using
.debs and dependencies would transfer the necessary logic from the
installer to the package management system. 

Here is a potential problem:  The package managers will be able to
handle pre-depends at some point[1], but will the algorithm result in an
installation sequence that is correct for installing hardware and
setting configuration parameters.

I can think of a few solutions:
Let the installer handle what dpkg+ would
- breaks modularity because the installer would need to know the
  relative priorities of the modules
Use the "priority" field as it is used now
- may not be fine-grained enough
Assign a numeric "priority"
- dpkg/apt/dselect may be affected[2]
Use a combination of text and numeric priorities
in the "priority" field
- ditto above
Add another field to a package's header
- ditto above
Use a textual priority for software packages,
a numeric priority for system modules.
- ditto above

I like the last solution; it would be simple to have dpkg+ do special
stuff with modules if they want, and provides a measure of separation
between packages and modules without the need for new code.


later,

	Bruce


[1] I've heard the pre-depends problem is being worked on, but I don't
know how close a solution is or if it is being handled in apt or dpkg.

[2] I changed the priority of a pkg to "5" and tried dpkg's l, s, and
C options, without incident; dselect created a new heading for priority
"5"; I don't have a clue what apt would do... I don't know if this is
design or accident.