Re: New 'Meta-Package' tag for the control file
>> "Kristoffer" == Kristoffer Rose <Kristoffer.Rose@ens-lyon.fr> wrote:
Kristoffer> I see this "problem" as an advantage: the user should
Kristoffer> *know* that removing a certain package means that his
Kristoffer> system no longer does the desired task.
Kristoffer> So -- I disagree!
This is not completely true. I created a task-gnome-wm package for the
slink GNOME update. It installs the GNOME compliant window managers,
as well as their themes and configuration utilities.
Now if I want to remove enlightenment, I will have to remove the task
package. And removing enlightenment will still do the desired task.
Adam Di Carlo pointed out that removing the task packages will also
remove the ability to track it with upgrades, so it the maintainer
adds something new to the task, the user won't see this.
So we have three more or less conflicting aspects:
1) Ease of use.
Removing some packages installed by a task is something really
needed and useful. The user may remove some critical package for a
task, because dselect and dpkg won't stop him. I think this can be
solved in a better frontend (see below).
2) Additional documentation contained in the task can't be installed
This can be solved by creating a package holding this docs with
equivs in five minutes.
3) A package not installed won't be upgraded in dselect and apt-get
{upgrade, dist-upgrade}
Solution is possible for apt-get and dselect, but has to be coded
(unlikely for dselect, possible for apt). See below.
I sent this to deban-boot regarding tracking of task packages.
This is indeed a conflicting goal. There is a easy way to solve this
(the other way around is clumsy):
The user can enter all task packages to track in
/etc/apt/task-packages. apt-get upgrade and apt-get dist-upgrade
will then automatically track these packages just as they would be
installed.
So tracking a task package is no problem, removing some of the
packages pulled by the task package is no problem as well. This also
allows for using the task packages as one-time selection helpers
(the empty netscape packages have been created with this in mind).
With the current way, tracking a task package is possible, but only
if one doesn't want to remove a package from this task. Removing
some package will result in a conflict (dpkg) or conflict resolution
screen (dselect), where one has to remove the task package. This is
a critical thing that should be avoided (especially for new users).
When the package frontend knows about the "task" status of a package
further things are possible. First, one could switch the programm
into "tasks" mode, then:
a) one shot installation
b) Tracking of a task package
c) Tracking of task package, with some dependencies excluded.
This can then look like:
* -- task bar -> one shot installation
+ -- task baz -> partial one-shot installation
+ package A -> install
+ package B -> install
- package C -> don't install
X -- task foo -> will be tracked completely
x -- task bonk -> will be tracked partly (new pkg. on task
x package D updates will be installed)
x package E
- package F
See? This extra semantic will do some good I believe. And if Debian
continues to grow that fast, such a thing is badly needed.
So we have to balance the advantages against the drawbacks of this
solution.
No problems, when the user uses apt-get or a frontend that knows about
tasks. Not ideal, when the user uses dselect or dpkg.
Without this flag, the tasks are only useful for one-shot installation
(partial installation is difficult), and tracking of the task is only
possible, if one doesn't want to remove one part of the task package.
The only problem is, that a dpkg -r is possible for parts of the task
packages, and one can't know if the user knows that he removes a part
of the task. But if he knows and wants this, he has to remove the task
package completely, loosing the ability to track it.
One can argue, that tasks (= package aggregations, the implementation
through dependancies is just a cludge strictly speaking) are something
for the package system frontend anyway. So directly calling dpkg -r
should not be a concern in considerations. So the frontend has to know
about tasks, and everything will work well (see my diagramm). I don't
expect dselect to be hacked to do so, but the apt frontends can
certainly be. And Jason said, he will do this, if the decision is
positiv about it.
Ciao,
Martin
PS: I prefer the tag solution to the seperate section solution, simply
because I think a task-grahic-foo task should be put into the graphics
section of the distribution.
Reply to: