my thoughts on package management

[Scott Becker]

On Wednesday 23 July 2003 05:00, Robert LeBlanc wrote:
 > As a case in point, if I happen to use IBM DB2 as my database of choice
 > (or necessity) on a given server, I'll end up having to (re)build
 > packages like PHP from sources in order to configure --with-ibm-db2 or
 > somesuch.

> The problem at the root of all this is that if I ever need to rebuild 
> anything from sources, I break the auto-update chain for that package.


What's the Big Picture/Goal?
RHL Project users get no "Support" from RH. Apparently this does not 
preclude RH from collecting money for RHN subscriptions to distribute 
and apply updates. Obviously for the example above, RH is going to 
provide support for DB2 in RHEL. RH's goal isn't to supply the serious 
do it yourselfer like Robert with everything he needs in RHL Project but 
instead in RHEL. Robert however, like myself, doesn't want to pay big 
bucks for support that we will almost never use (maybe his is willing 
but RH didn't speakup and say, "that's in RHEL"). We need to find a 
balance in all this. I see RH is being very careful but maybe too 
careful. If RH actually "is" willing support an array of PHP rpms, etc, 
for various configurations to cover the needs of people like Robert but 
"only" in RHEL and Robert is willing to pay for the convienence then 
that dialog needs to happen. Obviously RH is a large company which needs 
to make money so this is understandable but RH is being a little tight 
lipped about what they have going in RHEL and probably haven't decided 
it all yet.

On the other hand for people like Robert and myself who "aren't" willing 
to pay big bucks when we can do it ourselves but are willing to 
contribute to RHL Project, RH needs to work with us or lose us. I 
personally am considering moving to RHEL when 3.0 is released but I need 
to check it out first. They have said to me, "Talk to us, we give volume 
discounts. At low volumes." Not formalizing and publishing the volume 
discounts is very short sighted because more than half of the 
prospective RHEL customers my size never talk to them after seeing the 
price and multiplying it times the number of servers (7 in my case). We 
just say to our selves, "forget it, it cost too much".

If RHL Project is supported only by the community, then the community 
will move to one of the free update distribution systems if RH does not 
work with us. For example RHL Project is GPL. I can install it on 10 
computers or 50 computers. RHEL has a satellite RHN server. Because it's 
technically easy for the community to write a light version of this, we 
will (and have) if RH does not. We are do it yourselfers. Include in RHL 
Project a light RHN satellite that only the do it yourselfer can use:

rpm -i rhn-sat....
dhcp.conf: update_server=192.168.0.1
Done! Simple but not automatic. The masses will have one computer and 
pay for update the way they are now.

With this RH collects $100 / year / channel (or whatever) for a 
subscription which feeds the rhn-satellite all the updates only once. 
Then "Do it Yourself IT" can have an infinate number of installs in 
their company and RH never has to answer a single support call but is 
making just a little money from *many* small businesses. IMHO RH can not 
reserve convienient security updates for RHEL. But if they approach it 
from the right angle they can succeed big time. The other companies 
which are willing to spend $500K to save $2M will use RHEL for all the 
other advantages it has.

As for updating custom installs here is what is needed for both RHL 
Project and RHEL. Someone sugguested something close to this: All 
updates are released as not only bin and src rpms but also a src-diff 
rpm which installs patches for the update in an "unapplied patches" dir 
in the src tree for that package. This rpm is dependent on prior patches 
and the original src rpm. The only thing the do it yourselfer needs to 
do to take advantage of this when he needs to modify a package is to 
force the uninstall of the binary rpm first and then compile and install 
from the src rpm. Up2date will then do the right thing without mods. If 
we don't get carried away with diffs from every point to every point 
then this won't be very much extra work to support, just one patch rpm 
in addition to the src rpm (correct me if making a dif rpm is labor 
intensive). If the diff rpm cats an entry in a "src-update" log file 
then after running up2date -u the do-it-yourselfer only needs to check 
it for new entries to know which packages need recompiled. He then 
applies, compiles and then moves the patches to the "applied patches" 
folder and he's all set. Perhaps rpm can be taught to update a src rpm, 
simulating the diff rpm above, to accomplish all this without any other 
changes! A single update to rpm and a howto and it's all done!

I honestly believe RH can be a raving success if they strike a good 
balance between the do-it-yourselfer and the enterprise.

Sorry for being so wordy but I hope it helps.

    Scott Becker