> The caveats are that Vendors like RedHat often have > a significant > number of patches included with their builds. I > maintained packages > for a set of RHEL system for a few years, trust me, > it is not as easy > as it sounds to "customise" and rebuild packages.
Significant number of patches in their kernel packages yes. In many other cases, it is really just enabling some compile time flag in the spec file as you want that disabled feature. In other cases, you want to replace the thing like say Redhat packages postfix 2.0.x but you want your own patched postfix 2.2.x. > > It's especially painful if you want to say, update > the version of perl > included with RedHat to the newest version. The > dependencies involved, > plus the fact that you're replacing a package the > entire base system > relies on is not fun to deal with. In this case you have other distributions to pick from except of course, in your case you are already paying through the nose for a RHEL subscription... > > You can deviate to a certain extent from RedHat's > configuration, but > much beyond that and suddenly parts of the system > will "just break." This will only happen if you need to upgrade or customise a package on which many other packages depend. This case and the one above is bordering on build your own distribution if you need to muck about with a base package. > > The whole thing is not quick and easy to setup when > you are deploying > a set of systems for the first time without having > done it before. I suppose you want to say that Open Solaris/Solaris 10 is quick and easy to deploy for the first time? Nothing is quick and easy to deploy for the first time. That is why those who have a good number of systems to deploy and maintain have a staging system. > > The RPM spec file formats were poorly documented > when I was working > with it, and RedHat's perl dependency generator was > wrong most of the > time. Heh, glad there won't be any deb vs rpm flamewar raging here. > > Updating to a newer version of software for a > package often meant > finding which vendor supplied patches could still > apply or fixing them > so that they did so that you wouldn't be left with > bugs, or without > the customisations specific to the distribution they > applied that made > it a "RedHat-style" package. Yes this was a problem quite a long time ago. Redhat has long since gone into push things upstream (except for 'Redhat-style' stuff like configuration locations and initscripts) because they don't want to maintain their own patches too. Better keep them all at the source where they should be. > > The only relatively easy part was setting up the > repository with apt4rpm. > > Everything else was a rather painful experience for > me. What was required of you was a bit beyond maintain your own software stack. It was much closer to build your own distribution. I guess this is a hint for me... Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ opensolaris-discuss mailing list [email protected]
