Ross Walker wrote:
>
>> With java, you should be able to use the stock openjdk and tomcat5
>> packages (finally!) and be all set so it is a matter of dropping war
>> files in the right place. Even complex things like hudson or opengrok
>> will 'just work' (and if you do any software development you should
>> look
>> at both).
>>
>> On the other hand the guy here using ruby doesn't think the packaged
>> Centos stuff is usable. Realistically, it is hard to keep complex
>> modular tools where you want to use at least some of the very latest
>> parts in sync with what an enterprise distribution packages. That
>> might
>> be sort-of a plus for python if you can live with whatever version yum
>> needs and pay attention to what is going to break when it does version
>> changes.
>
> That is the truth.
>
> I wish the enterprise distros would "unbundle" the LAMP stack from the
> core OS, it just moves too fast to include in a long-term support
> program. They should make it a separately maintained but compatible
> add-on feature set (make a separate repo of it), maybe with a stable
> and current version branch.
Even better: admit that you will often need two or more versions of
every package to be installed simultaneously and make the package
manager able to deal with that (i.e. satisfying dependencies separately,
keeping them in different locations, etc.). It's not easy but that's
why you want a program do do it for you instead of tracking them
yourself under /usr/local or /opt. I suspect that a lot of places end
up running whole virtual or physical machines just because they need to
keep one old app working along with its replacement.
> I have always felt the distros include way too much in the core OS
> which could be better off in an "extras" or even "contrib" repo.
> Things like openoffice, firefox and the like don't need to be in the
> OS distribution, but available to install the latest stable version
> from the add-ons repo. Doesn't mean you can't include these on the
> media, sure, just as a separate repo on the media.
Again, this would really need the ability to install more than one. And
worse, some way to know when to integrate the libraries and when to
isolate them which is probably impossible to know for sure.
> It would be making, supporting and updating the core OS a magnitude
> less complex and would put the burden of making sure the LAMP or add-
> on packages are compatible with the core OS onto their respective
> maintainers or groups, but with proper notification and testing cycles
> it could be managed successfully.
Testing is the hard part here. It only works if you know that what you
tested is more or less the same thing that ends up running. When
multiple components, multiple versions and multiple repos are involved
it becomes very hard to know that. Particularly when your update tool
doesn't know where the version it is updating came from and will happily
overwrite it with something else from somewhere else.
> I also think there should be a single version of an OS that stays more
> current over time, not the bleeding edge but the stable edge. Instead
> of backporting kernel features, make small point jumps along the way,
> say from 2.6.18 to 2.6.20 when the latest is 2.6.26 and when the
> latest is 2.6.30 move to 2.6.24 and so on.
Agreed, but that more or less demands a stable device driver interface
so you can easily adapt the newest hardware to the kernel you are
running. Which sort-of rules out Linux.
> I think I've wandered too far OT now...
Yes, but most CentOS users probably face exactly these same problems due
to the nature of what it provides and what else you want the same
machine to do.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
