On Tue, Aug 15, 2000 at 12:28:12AM -0600, Jason Gunthorpe wrote:
> Well, this is what I was trying to say before - logically it makes alot of
> sense if packages are members of groups, this is the reverse of what we
> have now - a list of packages in a group.
>
> Delivery and storage of this data has *lots* of options..
>
> Let me outline more clearly how I think task packages should work from a
> users POV:
>
> The user should see a list of groups (I will call them this because I
> think groupings can be more general than just tasks). The UI tool will
> allow sorting and searching of the groups and when browsing individual
> packages it will be possible to see what groups they are part of.
Presumably sections and tasks will both be subsumed by this. I think
these should probably be handled differently: saying "I want the games
task" should probably default to installing all; whereas you'd probably
not want to say "I want the games section" and have all of them installed.
So maybe we'd rather cope with this by having different tags
with similar syntax, but different semantics, similar to the
Depends/Recommends/Suggests split.
So:
Package: psdoom
Section: games, admin
Task: bofh
Description: System administration with a rocket launcher
might be the way to go.
Changing the meaning of "Section" like this is probably dependent on
getting dinstall rewritten and the archive restructured first.
> The user can select that a group is of interest to them and mark it for
> 'installation'. Once done this means all packages currently in the group
> will be installed and all new packages added to the group in future will
> be installed. The UI tool will track when new packages are added to groups
> and present that information in conjunction with the traditional new
> packages display.
This sort of behaviour probably wouldn't be suitable for sections. Are
there any other "grouping" style things apart from sections and tasks
that we can consider?
> Important/standard/etc priorities would become mega-groups, most people
> would run with important and standard set to install - [like dselect
> does], but this becomes optional - and much more controlled.
Asked and answered. Heh.
This gives us a good excuse to actually follow policy and make all optional
(and above) packages simultaneously installable, too.
This makes the "extra" priority not really fit in though: while you can
(in theory) install all packages of any of the other priorities you
specifically *can't* do this with packages in extra. This priority is
more like the sections we have: it's useful to be able just view extra
packages, but all it is is a way of seperating them out, rather than a
grand unifying property of the packages.
Also, unlike sections and tasks, a package can't be in two different
priorities at once. So that's essentially the same semantics as tasks,
but a different syntax.
A slightly more orthogonal way of doing it might be more like:
a) Essential?
b) Standard part of a Unix system?
c) Can all be installed together without conflicting
So dpkg might be (a) but not (b), while nvi might be (b) but not
(a). Required is just (a), Standard is (a) and (b), Optional is (a),
(b) and (c), and Extra is whatever's left over. "Important" is ignored
as being silly.
I suspect you'd want a different interface to play with priorities than
with tasks though, too.
The other way of doing it that springs to mind, might be:
Package: freecraft
Groups: priority-optional, task-games/networking, section-games
(if you *really* group everything into just one way of doing things),
but I think this would probably require icky handling on behalf of apt
or dselect. It probably *would* make it much easier to introduce new
styles of groupings in future though.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgp9BaNMvF3lN.pgp
Description: PGP signature