[CentOS-devel] Centos server installation

[夜神 岩男]

On 08/03/2011 01:54 AM, Les Mikesell wrote:
> 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.

Then it wouldn't be @everything, now would it?

And that is how spins get born.

>> 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
> space?

Once again, removing something from everything makes it not everything, 
it makes it a "functional subset" known sometimes as a "system default 
installation" or a "spin" depending on how extensive the selections 
divert from the upstream view.

>> 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_?

You are underestimating the general public's ability to be fickle about 
technology they get for free yet do not understand.

> '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.

And how is upstream to read your mind and know to not include gcj for 
your concept of "everything" and exclude something else for someone 
else's view of "everything". This sort of gets to the root of the 
problem. I think we're having an Aristotle moment in logical semantics 
where everything equals everything and not something other than everything.

> 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 yum install "*" hasn't gone away. Are you saying this is too hard?

> 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.

Now you're talking. This is a great idea -- and I don't know a way of 
doing this other than through a script that parses the output of "yum 
list installed" -- which is something I did once upon a time to create 
.ks files with a little more ease than I had been doing. A lot of people 
do the same thing by being very patient with a click-through Anaconda 
install and getting the list from the generated .ks file, but that is 
sort of a pain and doesn't tell you anything about what you discovered 
after the installation, which I think is your real point.

I never made the leap to making it a push-button feature on the desktop 
(though that would be easy now that its thought of) or moving as far as 
to think of exporting the output into an Anaconda profile selection (the 
way you can select "workstation" or "development" or "server" or 
"minimal") -- but that would be pretty cool too and perhaps more cleanly 
achieve the effect you're after.

-Iwao