[CentOS-devel] Centos server installation

[Les Mikesell]

On 8/2/2011 12:23 PM, 夜神　岩男 wrote:
>
>> 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?

Call it "everything that's not broken" then.

> And that is how spins get born.

That's the reason spins need to be born.  Because there's not a good way 
to manage a list of packages.  Well, that and repository policies that 
pretty much guarantee that you'll need packages from third party repos. 
  Almost anything that spins can do could be done with a minimal install 
to the point that yum works and a package list.

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

No, I'm saying the people who haven't already memorized all of bash's 
quirky syntax rules are precisely the ones who would benefit most from 
having the largest working set of programs dropped in their lap to 
explore, man pages and all.  And leaving them on their own to figure out 
which few were the ones that you already know are bad to install 
together is a disservice.

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

That should be an 'informed' decision.  I'm assuming that the 
person/group who decides what packages are to be included knows 
something about them, but why assume that about anyone else?  You don't 
have to read my mind to know why gcj is wrong to inflict on people, just 
try to run a standard java program with it.

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

No, there are people who know what things don't belong together (hence 
the point that "*" or a real 'everything" is bad).  But that should not 
lead to a conclusion that they should leave the rest of the world to 
make that discovery the hard way by omitting a choice that installs all 
the programs that do work together.

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

No, I'm saying it is not quite the right set, and the person/group who 
decided 'everything' is bad knew why.  Discovering why by myself might 
be hard, though.

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

Usually it takes a lot of fiddling to get the right set in the first 
place, especially when you need to try some from different 3rd party 
repos and work around the likely conflicts there.

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

I think this could work on two levels - one as a local tool to duplicate 
machines (and perhaps it should include package version information to 
hold the update levels together) and another to mostly replace the 
concept of spins with a public central location to publish package lists 
with some commentary on why you chose that particular set and what has 
to be done to configure them.

-- 
   Les Mikesell
    lesmikesell at gmail.com