Michael Scherer a écrit :
Le lundi 13 février 2012 à 10:35 +0100, Thierry Vignaud a écrit :
On 13 February 2012 10:05, Olav Vitters<[email protected]> wrote:
- Suggests drakconf in minimal package
Why as part of task-gnome*, shouldn't it be a require elsewhere?
1) for symmetry with task-kde4-minimal
It should be done in task-{lxde,xfce,..} of course
Then it should be documented, because currently, task-* is polluted.
Since everybody add his pet peeves packages as task-*, that cause the
same problem that was intended to solve, ie too much choice. People have
the warm fuzzy feeling of having a selected and taylored set of rpm, but
that's far from the truth.
Right.
Also, it abuses suggests and interact in a weird way with auto-orphans
( or it should be better to say that it make it dangerous for users to
use the feature, thanks to the lack of semantics for Suggests, coupled
with lack of clear semantics on task-* and the abuse of the 2nd one by
the first one coupled with a too simple UI ).
2) so that people performing minimal install then installing task-foobar
got mcc too
(it's done at installer time through rpmsrate which is not used after
installation by urpmi -- else nothing will pull it[1])
So basically, that's duplication of information ?
3) because that's the right place to do it
Note it's a suggests, not a hard requires
Suggests semantics are still unclear. For now, that's "let me use this
to push totally unrelated packages in the default setup because I think
they should be installed but I have no way to explain why, and they are
important but not important enough to be documented or selected at
runtime". And that's far from being ideal.
I have exactly the same impression.
It gets messy to clean up unwanted packages.
In fact, the more I can think of, the more I wonder what was the problem
we wanted to solve with Suggests, and if we really did. The UI is near 0
and will be for a long time, since there isn't enough expressiveness in
a rpm tag for that. Advanced users, who are concerned with deps and what
is installed either remove suggests ( my case, because it pull lots of
unneeded stuff ), or just do without it for finding related packages
( because you still need to look on why something is pulled, and you
cannot really select ( not that asking a 100 questions would be good
OTOH )).
Less advanced users do not care at all about suggests in the best case
( ie, it solved almost nothing for them ), and end with auto-orphans
doing weird stuff. It also have a weird interaction model on upgrade
( like "if task-kde4 is installed, do I want to also pull all suggests,
even those I removed, or do I want to not do it, and then end with a
different result than from a fresh installation" )
So I would suggests ( no pun intended ) to just drop them. Keeping them
make us diverge from upstream, afaik, requires various hack with some
side effect and extra documentation for almost nothing ( ie, since we
may not have solved a real problem ), and think to do think another way.
This discussion reminds me of a model I'd like to see for task packages.
Thinking of rpmdrake.
Task packages show a tree of the packages to be installed.
Each required package simply shows a link to its' description. (As one
sees now for required packages.)
Each suggested package package shows justifying description line, in
addition to a link to its' description. And a check box to deselect the
item, so it is not installed.
So for example we wouldn't need a separate task-gnome and
task-gnome-minimal, since task-gnome would have everything more than
minimal as an option (or suggest).
We would have to have some means to indicate suggests already installed,
among other factors.
Although I see this model as primarily useful for task packages, it
could apply to any package with requires or suggests.
The concept is not new, it at least used to exist in the Microsoft
environment for larger packages.
Just an idea :)
--
André
