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

Package Management System

After reading a lot of documentation about the Debian Package Management
System (DPMS), i decided that i should post this.
The question is : would it be a Good Idea(tm) or a Bad Idea(tm) to
implement it ?
The DPMS goes beyond strict critical necessity (dependency & conflicts
between packages) with the 'Suggest' and 'Recommends' feature, which is
VERY useful when installing software. However the single package
approach is unable to handle some scenarios, where co-dependencies are

1.the Problem

I use this term to express the fact that two (or more) packages may need
to specify dependencies only when they are installed together. The
general case is when package A & B are designed for standalone use, but
support collaborate use too. Because the functionality provided by
these packages may be totally different, A should not suggest B &
vice-versa. However, if A or B is installed and the user selects the
other one, he should see that A & B suggest C, where C could be
documentation about collaborate use of A & B.
Some explicit examples :
Consider Apache and Webmin : when a user installs one of the two
packages, he doesn't have to know the relationship between them.
However, if both packages were installed, it would be stupid not to
see that you can install apache-webmin.
A second example which deals with i18n : creating empty language
packages would enable packages that have i18n extensions (package-lang1,
package-lang2...) to suggest or recommend only the most useful ones.
In a more general way, this system could 'guess' what the user wants to
do by having information about which packages are used together, and
suggesting appropriate software.

2.Implementation Proposal

I do not want to propose silly options that would huge changes in the
current system (btw, i didnt'read the code), so i'll stay in the
'package' idea.
I suggest some sort of virtual package (maybe a .deb with only the
metadata) to describe these kind of dependencies. Standard fields are
always there but their precise meaning slightly changes because of the
context :

Depends    : Mostly useless and empty. In an extreme case could be used
             to install conflict-solver software for N conflicting
Provides   : Also mostly useless. Only used if installation of N
             pacakges provides a feature without additional software.
Conflicts  : Certainly always empty, too. Could it happen that
             collaborate use of N packages generates conflicts ?
Recommends : Means "you would be stupid not to use this, which is
             specially designed to help you using the software you
             just selected".
Suggests   : Means "you have selected these N packages, certainly to
             do [use of packages], so your life would be easier if
             you had package Z".
Replaces   : Don't know.

An extra field is necessary to list the packages that are involved in
the multiple dependency, maybe "Tracks", "Watches"...


To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: