On Tue, 14 Jan 2003, Larry Brown wrote:
> I know that RedHat must get sufficient flack about the problems associated
> with rpms; however, I feel I must put my 2 cents in as well. This is the
> worst aspect of the OS. This is what really hinders RHL from taking over
> the world. I am a very patient person when it comes to PC's, which is why I
> work in this field. My customers can't understand how I am so patient when
> I am troubleshooting things. Yet I lose my patients trying to deal with
> dependencies. You need to add an app that needs 4 dependencies. You get
> out there on the net and find all four dependencies and download them to
> find the first rpm dependency requires 2 more, the second requires 4, the
> third thank god didn't need any and the fourth requires 2 more! Now we have
> 12 packages in addition to the original. That's not tough enough, now as we
> are installing one of them we have the problem listed below that one of the
> older versions is required for some other app to work so it won't allow you
> to install the new one. I know this has been described in detail and I
> really do love working with the OS in so many other ways so I'm not posting
> this to put down RH. It is just that for one, it is therapeutic to get this
> out. For two I also think there should be reminders from time to time that
> another operating system out there is configured in a manner that new
> software can be added without dealing with this kind of stuff. I think that
> the guru's of the world of whom I am unfortunately not a member of, should
> keep looking for a solution for the rest of us lower level shmucks.
There's really no magic bullet here. Without RPM, you'll try to install
something without knowing what lib it needs and have it not work. Then
you'll find you need to update a library, so you will. Then something
that depended on the old version will break.
If every app distributed it's own dynamic libs, you'd end up with what's
known in the Windows community as "DLL hell" (no, that other OS is not in
any sense immune to these issues). You have multiple copies of a lib
scattered all over the disk, some in different versions. A security
update comes out for that lib. Now, where are all the copies? Which ones
can be safely updated without breaking the app? If you don't update one,
what about the security flaw when you run that app? Will the original
vendor release an update?
If every app were statically linked, you'd have hidden copies of libs
scattered all over the disk and you wouldn't be able to update any of
them, ever. Will the original vendor issue an update?
The closest thing to a solution is really RPM combined with a dependency
manager such as up2date or apt. And even that won't work perfectly every
time. It would be nice if there were a standard, universal (unlike
up2date) dependency manager system, but I don't see Red Hat signing on to
apt any time soon. Up2date is probably a significant part of their
revenue stream. There is an open-source up2date server somewhere, but I
don't see other distributions rushing to embrace it either.
For local RPM collections, RH8 has the Red Hat package manager. It's
still a bit limited, but I believe they are working to make it better and
more flexible. We'll see. But this is not the issue that is preventing
RHL from taking over the world, and it's not so easy to fix that someone
else has already done it.
> Larry S. Brown
> Dimension Networks, Inc.
> (727) 723-8388
--
Matthew Saltzman
Clemson University Math Sciences
[EMAIL PROTECTED]
http://www.math.clemson.edu/~mjs
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list
