On Fri, 2006-06-02 at 15:21 +0200, Dag Wieers wrote:
Exactly, and I think we have to 'evolve' from a set of fixed repositories (in CentOS or RPMforge) to a dynamic range of 'appliance' repositories that build on top of the base OS and can be used next to the official repositories.
They may replace (update) core packages or fix things that are known to be broken to many people. If CentOS (wiki?) is able to funnel and manage something like this, I'm sure lots of the same cause-inflicted pain can be transformed into a community of appliance repositories.
If only there would be a good RPM build tool that provide conformance testing with simplicity.
Agreed. I've always had a vision of a few hundred sysadmins being able to publish their carefully tuned and maintained package lists in a way that would allow anyone else to easily duplicate their setup without knowing much about it. In some cases this would involve custom packages but mostly would be specific versions already available but not necessarily the latest in the repositories. In this case the 'testing tool' would be the administrator maintaining the master installation and any number of other machines using his package list would only update to match when he changes his list. Meanwhile very different assortments of packages/versions could also be available in the same repositories without having to maintain a separate repository to match every desired end user configuration.
I think this could sort-of be accomplished with the current tools using some invocation of 'rpm -q' to get a package listing in a format that could be fed to yum to install. To make it really handy, the yum repository configuration would have to also be automatically managed. (But, it never made much sense to me to have a tool that automatically manages your other packages but itself needs hand configuration...).