Re: Potato now stable
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
Reply to: