[CentOS] Open Letter to Lance Davis

Fri Jul 31 20:01:21 UTC 2009
Les Mikesell <lesmikesell at gmail.com>

Marcelo M. Garcia wrote:
> 
>> My 'dream' OS has always been one where the base install was extremely 
>> minimal - just enough to install the rest over the network.  Then there 
>> would be a way that anyone could 'publish' their installed list of 
>> repositories and packages and anyone else could duplicate that machine's 
>> setup just by picking that list from a set of choices with the installer 
>> dealing with the hardware differences for you.  This would eliminate 
>> most of the need for custom rebuilds and respins - at least for anyone 
>> with network access, and in my opinion the optimal combination of many 
>> thousands of packages is something that deserves to be be crowdsourced. 
>>   But, so far no one has done it and whenever the discussion of modified 
>> CentOS respins comes up the developers have seemed pretty lukewarm to 
>> the idea, as though it would devalue their brand.
>>
> Hi
> 
> The idea of a minimal installation is interesting. Could this be done 
> with a kickstart or a installation CD? Then you download/customize with
> "yum groupinstall <something>".

Sure - anything that gets you to the point of being able to run yum with 
disk and network access.  But there is a little more to what I want than 
a "yum groupinstall" can currently handle.  I'd like anyone with a 
configuration that they think is worth duplicating/sharing to be able to 
upload both their repository configuration and their installed package 
list to either a public or local server where that configuration would 
be saved with a unique ID, description, and author listing (and perhaps 
allow for user rating/comments).  Then anyone else should be able to 
give some command to update to match any of the ID's they want.  There 
are probably some hardware-related packages that would need special 
consideration in this scheme, but the worst part is that different 
repositories exist with different but same-named packages  and yum can't 
even keep this straight when updating the original machine much less 
reproduce it on another one.

> I think I didn't understand "it would devalue their brand". How could do 
> it if you reaching a wider public, working with more people with (more 
> or less) same goal? I would say "more" than "less". To me, as user, 
> seems that you will your brand more appealing.

The discussion was not about the scheme I'm describing, but generally in 
the context of either making a distro that wouldn't be called CentOS or 
one that had the Centos branding but modified content.  If I recall 
correctly, the former was grudgingly permitted but no help or advice 
offered, and latter was not permitted or at least highly discouraged 
unless it was a strict superset of the stock distro so problems related 
to the modifications don't affect CentOS's reputation.  Personally I've 
always preferred to install from the k12ltsp respin which is a fairly 
strict superset with a lot of useful additions.  However, it's not clear 
where that project is headed with the incorporation of part of its 
content into fedora packaging (but probably not others like the 
push-button commands to get flash, Sun java, realplayer, MS fonts,etc.).

> Besides, it seems, from the comment about the Fedora 10 tools, that the 
> customization could be easier in RHEL 6.

Yes, that will be a possibility, but building a million iso images that 
are out of date the next day and still won't have the exact setup you 
want just seems like the wrong approach.  What we need is one thing that 
handles hardware differences (and might also fix things up if you move a 
disk from one machine to another or restore a backup on a new machine) 
and another thing that can save and re-install lists of packages 
repeatably even if the repositories won't cooperate with their package 
names.  The rest would happen by itself as people came up with 
interesting combinations of packages tuned to different purposes and 
optimized for different types of hardware.

--
   Les Mikesell
     lesmikesell at gmail.com