On Mon, 14 Aug 2000, Joey Hess wrote: > > * Tasks are great, but task-* packages suck when some of the > > packages included have release critical bugs. (Remove the > > package, the entire task breaks) > > You know, if apt could only support Reccommends, task packages could be > a lot saner. Sure, it'd still be ugly if something they depended on went > missing, but at least they'd still be usable. > > I think apt could support reccommends like this: > > * Automatically install all reccommended packages when > installing/upgrading a package. > * If a package that something reccommended was manually removed, don't > re-install it next time a package that reccomends it is installed. > > Of course whether this is doable is up to Jason..
I don't care for this much, it breaks the model that apt-get follows, it adds this extra variable of 'things that were removed' which can lead to subtle unexepected behavior. The way it is now the command line tool consistently ignores recommends/suggests, like dpkg. Higher level tools are free to do whatever they want. Tasks are bettered handled through some kind of non-package means. I've long said we need to determine some kind of meta-package scheme (a 'package' whose only purpose is to logically group other packages). Clearly the desired effect of all meta-packages is to provide the user with a single node to manipulate and view a group of packages. They should have special properties in any UI, you should be able to view and manipulate their grouped packages. Idillicly the grouping would have priorities of packages (ie -python doesn't need to install every freaking package, but some are definately critical) and the ability to track and optionally install new packages added to the group, remove the whole group, etc. All this data is orthogonal to the dependency structure. Perhaps if some thought is put into this a rational solution to the package splitting problem can be found (convert the old 'big' package into a meta-package before touching the original 'big' package -> provides a simple and safe transition?) If you take this thought to it's logical extent then things like the important priority are mearly hard coded examples of this. Logically, the way to represent this is to have package declare their membership in a grouping. This could be done via the override file so as to maintain a centralized authority like we have no with the task packages. Groups and user preferences about them could be stored seperate to the status file. Jason