Re: Potato now stable
On Tue, 15 Aug 2000, Anthony Towns wrote:
> What I'd like to happen is basically be able to remove the package,
> and just have the task automatically act as though that package had
> never existed. Not complain in dselect about it, not worry people when
> Apt gives you a warning, not do anything.
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.
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.
A tree-like display can be used to show what packages are part of a group
and allow individual selection. Since some groups are quite large it may
make sense to categorize the packages lists into finer subgroups
(primarily to help the user navitagate around, but they could be seperate
at the top level too) that can all be individually selected for install.
[Example: task-python-critical, task-python-web, task-python-gui]
Since there is a tree like display the user can pick off individual
sub-packages of the group, which would now serve nicely as an
oganizational tool. Packages may belong to many groups and appear in
multiple places in this tree - again for organiation.
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.
I can see that blacklisting within a group may be useful on a limited
scale. The blacklist would be expressed as 'packages a1,a2.. in group b
are not to be installed, but the rest of b is' which allows undesired
components to be eliminated by the user. Most groups should be designed to
minimize this, hence this is primarily aimed at the mega-groups rather
than smaller ones. (This is a similar, but stronger statement than your
original proposal - not automatic either)
So now we can bring organization in on a grand scale. I can envision task
package groups that are like we have now, small very focused things,
priority groups which reflect the standard UNIX view of a system, and new
kinds of purely organization groups (how about a gnome mega-group?). We
could bring some sanity to the section arrangement by having things be
part of multiple sections, and provide stronger guidelines and more
sections.
And if you recall what I said in my last message about recommends - take
this same concept and apply it to a 'micro-group' of a single package
(where recommends and suggests form sub groups) and you have a simple
understandable concept that can be applied and used for about 5 different
things! In my book that a good thing!
If we can work out the details I think an idea like this could help in
*alot* of areas, and is not really super complicated for us to deploy!
Jason
Reply to: