Anaconda is not the place for pedantic customization

[Jef Spaleta]

Chris Ricker
> None of your ideas work with the current setup, which is that RH's >
package 
> developers are putting non-essential dependencies into RPMs just to allow 
> upgraders to get the new non-essential software

Oh, I'm working under the assumption that the debate over the moral
superiority of the non-essential deps is already over. The non-essential
deps is clearly a kludge to fill a need in place of a better technical
solution that does not exist yet. Whether people in the community can
step up to the plate and help implement a clean technical solution that
meets the need provided is to be seen. But I'm arguing that any
technical solution as a replacement for non-essential deps that requires
anaconda to offer package grouping choices is a bad one.  You pick your
fights, I'll pick mine :->   

And other than the Suggested/Recommended dep tagging being added to
packages I'm really not sure that any other offered solution will work
for the cases the non-essential dep tagging is being used for. I'll
admit I'm having a hard time following Jeremy's back and forth over
using the comps files and groups to try to fill the same need the
non-essential deps tagging tries to do. But trying to do this in the
comps file sure looks really fragile to me. And as for the
Suggested/recommended dep tagging..thats going to be a big technical
hurtle to try to climb to get implemented. But who ever said the right
way was the easy way.

> My point is that the claim that that's necessary isn't true. There are other 
> ways to give upgraders the chance to get new software, without forcing that 
> new software down everyone's throats as the current status quo does. 
> Anaconda, firstboot, etc. are all possible places to present it -- the 
> important point is that a choice can be offered, not the details of where / 
> when it's offered.

It's clear the goal to date has not been focused on providing ultimate
configurability over what is installed. The focus has clearly been to
make sure that the software 'preferred' in a general usage scenario is
installed so mere mortals do not suffer from lack of
functionality/featuritis. The general use case is no customization. If a
solution that gives you more customization control does not work
reliably or is much harder to test and debug for the general use no
customization scenario...its not a good solution.

I'm still not convinced that you can 'reliably' use the comps file
groupings to make sure the 'preferred' software gets installed for the
general use case where there is no customization desired at
install/upgrade time. I can't help but thing moving the equivalent
'preferred' functionality that the non-essential deps try to provide to
the comps file that anaconda sees is going to be significantly harder to
test and debug, simply for the very fact that most testers are not going
to volunteer to reinstall/upgrade their boxes every day using the latest
installer images to test for specific comps file bugs concerning the
split between preferred/essential packages.
I don't think a solution that can not be expected to work reliably in
the 'no customization' case and involves a much more complicated testing
scenario to debug is a better solution.  

-jef