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

Mon Feb 13 19:14:10 CET 2012

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é
+
+