[CentOS-devel] Centos server installation

Tue Aug 2 16:54:58 UTC 2011
Les Mikesell <lesmikesell at gmail.com>

On 8/2/2011 11:25 AM, 夜神 岩男 wrote:
>> Agreed - it is something that upstream should provide too.  Or at least
>> a yum group or list of packages in a form that yum would understand to
>> install them later.
> This was discussed, exactly the way you are stating things on one side
> "wouldn't it be nice if..." VS "the uninformed are the majority who
> choose the 'everything' option and when things break they assume the
> whole distro sucks and ditch it" on the other.

It's not an either/or decision if someone who understands the 
potentially conflicting packages picks one (and only one) to include in 
the 'everything' set.

> Which would you prefer be the newcomer impression of CentOS? A system
> that works well with adequate defaults but that can be explored to the
> heart's content (which entails research -- on any OS -- how many people
> do "everything" AIX installs -- they either don't do them or receive AIX
> package selections that are strict defaults with nothing further
> vendor-provided?) or one that gets overloaded with conflicts and breaks
> because too many conflicts are installed and things that are supposed to
> be simple, like starting or stopping slapd, become complex in ways
> unknowable to the user?
> In short:
> The chance that a knowledgable system administrator is going to be able
> to research how packages interact in a desired setup...
> ...is a lot higher than...
> ...the chances that the average person who is prone to click
> "everything" will know how to manage the situation he's put himself in.

What situation would that be if someone vetted the packages and 
'everything' didn't include conflicts?  Wasting a dollar's worth of disk 

> This *was* a feature in the past and was removed for a reason. You can
> head back to FESCo and re-argue it, but I found the case for removal
> compelling, particularly with the 'yum install "*"' option available for
> those who know what they are doing -- and that begins with understanding
> why the "s are necessary in the command.

Ummm, _what_?

> This was a revealing threshold, as it turned out once the feature was
> removed -- most of the complaints/questions on the users at fp.o list about
> removal were from people who really didn't know what quotes do in
> bash... which sort of validated the whole debate in favor of removal
> after the fact. This was the precise demographic that had no business
> clicking "everything" and was the only group clamoring for the
> reinstatement of @everything.

'everything' should not mean "*".  It should mean everything that is 
sensible, according to someone who actually is familiar with all of 
them.  I'd be perfectly happy if it didn't include *gcj*, for example, 
since I can't imagine that as ever having been good for anyone.  And 
while I'd prefer sendmail over postscript I'd be able to deal with 
someone else making an informed choice there.

> There is history behind this decision. Of course, CentOS is not
> upstream, so it could go its own way, but I think thoughtful
> contemplation of the issue at hand (making a dangerous edgecase widely
> available on an enterprise-level system) they will likely stick with the
> status quo.

I know there is a history.  I used to use everything installs, found it 
useful in discovering and testing programs, miss it, and don't believe 
that the people you think you are 'protecting' by omitting it are going 
to do better at choosing non-conflicting sets by themselves given yum 
and a list of thousands of package names than someone who was involved 
in choosing the set included in the distribution could.

But, something else that I've always wanted to see might be even better. 
  I've always thought that there should be a push-button way to export 
your list of installed packages (and I suppose this should include 
repositories...) so that anyone who thinks he has configured the perfect 
setup for any particular usage could publish it, and anyone who wanted 
to duplicate that setup could do it in a completely automated way.

    Les Mikesell
     lesmikesell at gmail.com