On Thu, 8 Nov 2001, Paul Lussier wrote: >> So, the problem is not with RPM, per se, or even with Red Hat. The >> problem is that the paradigms of the two approaches are fundamentally >> different. > > While I agree with this completely, it seems there should be a way to > take the dependancy findings of rpm, invode rpmfind to locate them > and then use rpm to retrieve and install them all automatically > without manual intervention.
There is. The problem is, since distro X and distro Y are very likely to have a different dependency tree, you tend to get dependency solving which is either tied to whatever distro the initial package was built on, or just plain broken (or both). Again, this is not an issue APT faces, because there is only one popular, long-lived APT-based distribution -- Debian itself. There have been a few APT-based distros, though. I am curious as to how well things worked for them if you told APT to go to Debian's repository. With any significant divergence from the Debian base, I suspect APT would want to "upgrade" significant chunks of the system for every package you wanted to install. (And if the distro does not differ significantly from Debian, what's the point?) I am not sure this is a solvable problem. Binary packages are highly dependent on their build environment. I do have a half-baked idea for something that might work: A cross between RPM and BSD's "ports" system. Imagine a system that would let you download a source package which included RPM/DEB-style package information. It could build it locally, creating a binary package for your configuration automatically. It could then install that binary package, tracking installed files and dependencies. This binary could also be distributed for configurations matching the build environment. As I said before, implementation of the above is left as an exercise for the reader. :-) > However, and this goes back to your statement about them being > fundamentally different approaches, Debian's approach also sets up some > kind of responsibility hierarchy ... And I am sure Red Hat has a similar structure internally. The key point here is that rpmfind searches *any number of distributions*, which all have their own hierarchy, or lack thereof. :-) If there was a tool that searched for .deb packages outside of Debian, I am sure you would run into similar problems. However, Debian's approach of community development makes it unlikely that such a tool would become popular; it is more effective to simply get the packages accepted into Debian's repository. (As an aside: This does create a single-point-of-failure scenario. If anything happens to the Debian repository, serious lossage will result.) > RH enforces nothing as far as 3rd party contibuted packages. And Debian does? If I grab a .deb package that is just hanging out on some guy's website, how does Debian make sure the guy who built it wasn't a complete idiot? :-) Again, the subtle point here is not that Debian's package tool works better. All other things being equal, I suspect they are all about the same. Debian's advantage is that the barrier to entry for their package repository is lower. They can have more Debian-compliant packages in their repository than any commercial distro can, because their system is based on public contributions and individual accountability. > RH really wants to control what goes into a distribution ... Debian has > no such desire ... Not precisely true. Debian has fairly strict guidelines for accountability and policy. The difference is better described in terms of what the controls are trying to accomplish. Again, Red Hat is basically trying for a discrete product; a software release where everything works together in a big, happy, Red Hat family. Toward that end, they have to create an internal system of package evaluation, development, and QA (if "Red Hat QA" is not a complete oxymoron ;). Debian appears to be more more focused on creating a system where packagers provide building blocks (the packages) which the user can easily use to build their own preferred configuration. The focus of Debian packages is not getting the whole thing working as a cohesive whole, but rather, making sure that everyone speaks the same language. What you say with it is up to you. (I am bending those metaphors quite a bit there, but I think it gets my point across.) > RH is a distribution for the profit by company. Therefore, they have no > real incentive to make it easier for you to install packages which are > not located in their distribution/on the CD. Not true. In fact, I would say the opposite is true: RHS wants to make it as easy as possible for ISVs to provide software that works with RHL. A platform with no ISVs is dead; OS/2 showed us that, and Red Hat is not stupid. What RHS does not have an incentive for is making RHL particularly compatible with other RPM-based distributions. If RHS was really clever, they would create a Red Hat-sponsored registry of third-party RPMs built to work with RHL. Hmmmm. I wonder why they have not... -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
