From hearing the Solaris admins around here complain, "solved" might be a bit strong. :)
Well, I never said it is perfect ;-)
For example, single Solaris patch can patch more than one package. If you don't have all the packages installed, it will patch only those that you have. If you add a package, you need to remember that you need to reapply the patch. This was quite annoying.
Anyhow, the only really big problem with Solaris system that I had was occasianal recommended or security patch that depended on non-free patch (some patches for Solaris you have to pay service contract - not to mention that there are some important patches available only under that same service contract). Luckily there was that German site where you could download those (uh-oh, I lost the URL, is it still running, anybody?)
But I guess we wouldn't have that kind of problems with Red Hat ;-)
I worked with both systems, both have good and bad points. As I already wrote, ideal would probably be somewhere in the middle. Something to allow user to download only changed files (kind of rpm diff) and use that diff file and original rpm to generate updated rpm. In my previous post I wrote that only the signature would be missing. Given more tought, it isn't the case. Diff rpm file can include signature that resulting (generated) updated RPM should have. It can be used to check if updating the rpm package was successful.
After sleeping over it and thinking about it while sleeping ;-), another approach without regenerating updated packages would be if rpm tool could apply changes directly into the installed package (bumping its version number, just as if updated package was installed). This should be possible too, since patch file (or diff file, same thing) can contain all information, with all checksums and signatures that need to be placed into RPM database. Basically, the result would be the same as if user downloaded and installed updated package. With good naming conventions, this could work with yum and apt-get without any changes to those two tools.
But again, the question is, is this added level of complexity worth it?
-- Aleksandar Milivojevic <amilivojevic@xxxxxx> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
