[CentOS-devel] Centos server installation
lesmikesell at gmail.com
Tue Aug 2 16:54:58 UTC 2011
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.
> 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.
lesmikesell at gmail.com
More information about the CentOS-devel