Re: package pre-selections tool
On Mon, Apr 06, 1998 at 10:13:30PM -0400, Fabien Ninoles wrote:
> An example?
> Package: C Development
> Recommends: gcc, gdb, libc5-dev
> Suggest: clint, ddd | xxgdb, bison, [put on a second line for best view]
> emacs | joe | emacsen, kernel-package, kernel-source-2.0.33
> Description: Debian C Development Package
> This choice gives you the bare minimum if you want to do some
> programmation on your computer. In fact, it gives you everything you
> want for recompiling your kernel, one of the most primordial task to
> do for every Linux hackers.
While we're looking at alternate ways of doing package pre-selections, how
about the reverse: each package has a field listing the pre-selections that
it belongs to.
This works sort of like the "menu" package, and is much more scalable (and
maintainable) than simply listing all the packages that belong to a set. A
package can belong to more than one group, and Apt would automatically pull
in dependencies if you enable a group. So, for example, 'jed' could have a
Preselect-Groups: text-workstation, developer
Meaning that 'jed' is useful on a text-based workstation, or in general for
a software development box. With this approach, pre-selections do not need
to be mutually exclusive, either.
The other advantage of this, as I hinted above, is scalability and
maintainability. A new package can add itself automatically to the
'developer' set, for example. If the package disappears, it is simply no
longer part of the 'developer' set.
Maybe we should have sublevels too: for example, "objective caml" isn't
exactly important for most developers, but Real Programmers who must have at
least one copy of every langugage in existence might want it. On the other
hand, perhaps this is adding too much complexity, and it's best to let
people add their own entries when they get to that point.
Just thinking out loud...
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com