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
