[Mageia-dev] [changelog] [RPM] cauldron core/release task-gnome-3.3.2-4.mga2

[andre999]

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<olav at vitters.nl>  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é