Michael Torrie wrote: > Don't mistake old packages for stable. And I don't think you can make > the case that all the packages in the debian repositories receive a > tremendous amount of Q&A. Some do. But I can say that a certain level > of Q&A has gone into every package Red Hat ships. The infamous Debian > openssl issue a while back highlights the problem with Debian's > stability. Also things kind of went downhill when some core debian > people left the project. One went to Sun to work on OpenSolaris; I > think there were others lost as well. > I'll argue this. The packages that make it in to testing go through just as much QA as an "enterprise" release. Packages moving from the unstable release to the testing release must meet the following criteria:
* It must have been in unstable for 10, 5 or 2 days, depending on
the urgency of the upload.
* It must be compiled and up-to-date on all architectures it has
previously been compiled for in unstable.
* It must have fewer release-critical bugs than, or the same number
as, the version currently in testing.
* All of its dependencies must either be satisfiable by packages
already in testing, or be satisfiable by the group of packages
which are going to be install at the same time.
* The operation of install the package into testing must not break
any packages currently in testing.
When the release-critical bugs are approaching zero, testing is ready to
be moved to stable.
Now, compare that to Red Hat. Fedora is the "upstream" distribution for
RHEL. The technologies in Fedora are the testbed for RHEL. When Red Hat
determines the technologies are stable enough, they release RHEL.
Granted, not everything in RHEL comes from Fedora, but most does. It's
fairly accurate to take Fedora 6 if you want to see what RHEL 5 is like.
Same will be true for RHEL 6, whenever that releases.
However, have you ever taken a look at the full RPM package names on
many of the packages in RHEL 5? There are many, many packages in that
have ".fc6.rpm" in them. Trivial, sure, but are you going to tell me
that Red Hat is doing quality testing on every package in the operating
system? I don't buy it. I don't buy that their QA department is doing
anything more than what I just outlined for Debian stable either.
> I'm a strange one in that I think if you have something that works for
> you, why change? I like Ubuntu fine, for example, but I'm running
> Fedora and it works very well for me. So I don't see what changing to
> Ubuntu will do for me.
>
Use what works for you. Don't change because someone else says so. Sure,
there are _really_ bad operating systems out there, but what's been
discussed so far on this list, are all quality operating systems. I use
Fedora in a virtual machine all the time for development, but Debian as
my main operating system on my laptops and desktops. It's what I'm used
to. It's what I like. And that's all that should matter. After all,
aren't we all on the same team?
> On the RPM note, I'm always amused when people talk about RPM's short
> comings and then go to compare it to apt, which is a silly comparision.
> RPMs are equivalent to .debs. In fact at that level I can't see any
> difference. RPMs do have one advantage over .debs. That is that they
> handle multiple architectures fairly cleanly and smoothly. In other
> words RPM can deal with the idea that I have two identical packages, one
> 32-bit and one 64-bit than can both be installed without causing
> conflicts. This a big deal for me, since all my servers are 64-bit and
> occasionally I need to deal with a 32-bit binary for whatever reason.
>
RPM has a couple advantages over DEB. First, it uses a back-end binary
database for keeping track of what's installed, etc. Using this
database, RPM can be used as a light HIDS with 'rpm -V' as well. With
delta RPMs coming out (have they come out yet, I keep hearing about it),
this makes downloading and installing updates a snap.
On the flip, Debian has taken the more standard Unix philosophy. The DEB
"database" is nothing more than flat files in plain text. You should be
able to read the database with any plain text editor, rather than rely
on binary tools. If you want to use a HIDS, then you shouldn't be
relying on the DEB database. You should be using something built for
that purpose, like AIDE or Tripwire. Lastly, DEBs aren't built on top of
CPIO, but gzipped tarballs instead. I personally find this superior, as
CPIO is an obscure technology, that only RPM is using. Everyone else in
the world are using tarballs as well.
I will say, that I find it rather amusing that "yum" comes from another
operating system, not Red Hat. Odd that an "enterprise" operating system
will rely on 3rd party utilities to solve their problems, including
their own package resolver "up2date". I guess that's what the community
is all about though, right? :)
> And functionally, apt and yum are equivalent as well (speed issues
> notwithstanding). Yes synaptic is wonderful, but it's a usability
> nightmare for non-geek users.
>
Personally, I've never discovered dependency hell with Debian. I did
with Red Hat. Before Red Hat shipped RHEL, and before they released
up2date, getting software on a Red Hat system was a nightmare. Making
sure your libraries were the right versions, making sure you didn't have
conflicts, chasing down dependencies with the right versions for what
you were installing... I saw no need to run a Linux operating system,
when Windows software had all the dependencies in the executable, and
installing was as simple as a double-click.
When I was running Red Hat Linux, I shared this nightmare with a friend,
and he said "use apt". What's apt? I had no clue, so I Googled, and
found Debian in 2001. RPM hell no longer existed in my life, and
installing the software I wanted was as simple as "apt-get install". Sweet.
> Finally, dependency hell happens regardless of packing system and
> resolver. Even on Debian (happened to me).
>
On both my RHEL servers and my Fedora virtual machine, I occasionally
come across packages that Yum can't resolve. I know others who have had
this problem as well. On Debian unstable only, I will have a package
every once in a while fail to install, because some version that the
package is looking for is either missing or not up-to-date. Right now,
it's "sagemath". I've never experienced any dependency issues with
testing or stable though.
> --------------------
> BYU Unix Users Group
> http://uug.byu.edu/
>
> The opinions expressed in this message are the responsibility of their
> author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG.
> ___________________________________________________________________
> List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
>
--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O
O O O . O . . O O O O . O O O
signature.asc
Description: OpenPGP digital signature
-------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
