On Tue, 2004-12-07 at 13:56, Kwan Lowe wrote:
> Initially there were problems with database corruption requiring rebuilds or
> kludgey workarounds. Package installations could leave a system broken. This
> said, except for non-RPM OS issues (e.g. drive failure, filesystem related
> corruption), I haven't had an RPM database issue in over two years.
There were some _major_ bugs with RPM v4 when it was first released in
Red Hat Linux 8. I know, I ran into them.
> The biggest complaint about RPM today is "dependency hell". It's infamous
> enough that it's instantly recognizable like "blue screen of death."
> Dependency hell is not a bug. It's a feature. Seriously. This is RPM doing its
> job. It's letting you know that a package requires certain versions of
> libraries or needs other packages to work correctly. Imagine if it didn't do
> this checking (i.e., you ran a tarball based installation with requirements on
> system libraries). The program may run for a while but then you may get a
> weird bug. Because the program seems to run you start looking at other things.
> Maybe you spend time diagnosing the system itself, maybe even delve into the
> code. Believe me, you want the package manager to warn if version dependencies
> are not met.
I think people confuse "dependency hell" with "nothing like APT hell."
Dependency hell will _never_ go away with DPKG, RPM, etc... "packages"
distro "back-ends" in general.
But the "nothing like APT hell" is _gone_. Any RPM distro these days
lacks it. Each vendor provides a "front-end" like APT to _their_
repositories.
So then the question becamse, what about 3rd party packages?
If you're looking for the wealth of the Debian repository, forget it.
It ain't going to happen now, and maybe it will _never_. But there
_are_ a lot of vendor-independent repositories out there for _any_ RPM
distro.
In the case of Red Hat, out of the numerous reasons for Fedora (which
had been brewing since the introduction of RHAS/RHEL in 2001+), the name
Fedora came _specifically_ from the most stable, independent repository,
the Fedora Project out of the University of Hawaii. Red Hat wanted to
build an "official" repository of 3rd party packages. That is now
Fedora Extras. It also wanted to build an "official" repository for
older distributions. That is now Fedora Legacy.
There are still other, Fedora "Third Party" (that is Red Hat's
"official" name for them) repositories, but they are not funded by Red
Hat, nor are their packages signed with an "official" Red Hat key. But
Red Hat has recognized that offering a direct avenue for the community
to provide packages is the best thing they could do.
> Then there are package dependencies. You want to install one RPM but get an
> error that another RPM is required. Or not. Maybe it just gives "libfoo.so.217
> required." This is the hell that most people talk about. Admittedly, RPM by
> itself can only warn if the dependency is not satisfied. It is up to the
> distribution to ensure that package dependencies are complete in the
> distribution. Think of RPM as the engine behind the user friendly package
> management tools. It allows you to type "yum install ogle_gui" and
> automatically get the DVD libraries, ogle, etc.. Mandrake and Suse have
> similar tools.
_Exactly_. Even APT uses DPKG on Debian. Some people don't recognize
that. I literally had a huge, long flamewar (naaah! really? me? ;-) on
JAXLUG with a guy (guess what distro he ran? no, not Debian, another ;-)
that said "Debian uses APT, Red Hat uses RPM" and he even provided links
as "proof" that only basically said _exactly_ what I said. That APT
uses DPKG on Debian.
APT was designed for DPKG. APT was designed for Debian. And there are
some DPKG-specifics to APT that are not in RPM, so APT-RPM versions
don't have them (largely source and config portions). But a front-end
is a front-end, a back-end is a back-end. I can use APT-RPM, even if
Red Hat _only_ supported YUM-RPM.
> I'll also add that most of the dependency problems I've seen are because of
> improper packaging. Some packagers may require a particular package, including
> version, rather than having a service satisfied. I.e., you can specify that a
> package needs an FTP server rather than ProFTPD 1.2.3. Sometimes one distro
> will use a non-standard name such as libfoo123-xxx.rpm because they build a
> compatibility library. Moving this package between distributions can cause
> problems until those dependencies are properly updated.
Most of the "interdependency non-sense" was probably priority #2 for
Fedora, and still is. If you're around on the list, a lot of Red Hat
people _beg_ for others to find _stupid_ dependencies in Core. Several
people in 2003 at Red Hat developed a number of tools for dependency
mapping, and these were _crucial_ in eliminating a lot of the non-sense.
There are now guidelines on packaging and package installation
requirements. Not nearly as tight as Debian, but much, much better.
As far as multiple versions and alternatives, those were _perfected_ in
RPM v4.
> Another complaint about RPM is that it's not as well-tuned for the machine as
> source-based distributions.
Fedora is i486 ISA, i686 (FC3=P4) optimized. Yeah, it's only -O2. But
_no_way_ am I running with -O3 -- _no_way_.
> Actually, I think it's easier to build using the RPM system.
But is it effective? As I mentioned in my response to Chad, it's
_still_ up to the "packager" in a "packages" distro just like the
"porter" in a "ports" distro to _modify_ the Makefile. Otherwise, the
software gets the _same_ options.
> One of my favorite features of RPM is that you can package the sources and the
> build instructions in a single file. It allows easy specifications of base
> directories and build environments. This allows for easy reproducibility.
> I.e., three months later if I want to recreate a package I can do so with a
> single command. This is vitally important for maintainers and anyone who needs
> to support software.
Configuration management is the most _under-recognized_ key to Open
Source adoption. People talk about how Linux adoptions fail. They do!
Because either the project did not address configuration management, or
failed to realize that there is _little_savings_ to be gained in
configuration management over other platforms.**
[ **NOTE: Now when it comes to patch management, Windows systems have a
_much_ higher TCO. Not because of the patches, number or other,
commonly stated details, but because patches _conflict_ with one
another. This was the #1 reason why SQL-Slammer hit _bad_ -- because 2
subsequent MS SQL patches _silently_uninstalled_ the one that would have
prevented Slammer. ]
The same thing happened in the aerospace industry. After Sojourner
(Mars Pathfinder) was a success of the GNU/VxWorks platform in the
mid-'90s, more COTS (commercial off-the-shelf) projects took over at
NASA. Unfortunately, with the hardware and software budgets being cut
90%, so was Quality Assurance (QA) by 90%! The result was the Mars
Polar Observer-Lander mishap where two engineering teams were using
different units!**
[ **NOTE: This is the #1 reason why I told my middles school students
that tracking and recording units are _important_, even in the age of
computers. Because while computers crunch numbers fast, units are far
more abstract and not done in digital/software because they would slow
down computations rediculously. Heck, even in calculators, they are a
pain compared to simple, human "dimensional analysis." ]
> If I have two systems running the same Linux version/distro on different
> hardware (e.g., AthlonXP and a '586) I can use the same source package and
> build packages for each architecture with two commands. In most cases I'd want
> to build on the fast AthlonXP and then deploy only the binaries on the other
> machine.
If you have floating-point, optimizing even just -O2 for an Athlon is
_mega-big_ -- up to 40%.
> This happens regularly for web systems when building Apache and PHP.
> For various reasons I keep development tools off my web and email servers. So
> I could so "rpmbuild --rebuild --target=athlon some.src.rpm" and "rpmbuild
> --rebuild --target=i586 some.src.rpm". I would then have packages specific for
> each machine that I could install.
> Other package management tools can do the same things. In fact, the difinition
> of a package manager probably requires dependency checking and
> reproducibility. So it's a matter of personal preference for me and I'm not
> implying that other tools cannot do the same thing. About the only feature I
> would wish for is easier rollback. Fedora Core 3 and some of the RedHat
> Enterprise offerings allow this with varying success so there's hope.
> Sorry for the long email.
Aahhh, we welcome you Brother Lowe! ;-ppp
-- Bryan J. Smith b.j.smith@ieee.org ------------------------------------------------------------------ Beware of advocates who justify their preference not in terms of what they like about their "choice," but what they did not like about another option. Such advocacy is more hurtful than helpful.----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:41:54 EDT