[NTLUG:Discuss] Re: Debian -- considering switching to Debian

[Bryan J. Smith]

"Peter A. Koren" <p.koren at worldnet.att.net> wrote:
> I am currently using the Scientific Linux Distribution
> which is essentially a tweaked version of Red Hat
> Enterprise Linux 4. I have been installing applications
> from a small number of compatible repositories.

The problem with standardizing on Red Hat Enterprise Linux
(RHEL) or SuSE Linux Enterprise Server (SLES) is that they
are purposely designed to be "trailing edge" releases.  This
is because they are designed for Service Level Agreements
(SLAs) where only a select set of 3rd party packages have
been certified against their releases.

If you are looking for flexibility and package availability
in a distribution, you should not be running RHEL and SLES. 
They should be the least interesting of releases.

> From doing this, I think I now understand the answer to
> the question I posted here about a couple of months ago
> about the best system to resolve dependencies and I have
> discovered (later than most I'm afraid) that a large well
> maintained repository is the key.

It's commonplace.  People get so riled up on brand names and
everything else that they fail to see the commonalities among
solutions, and what ends up being best for any.

Dependency hell with "packages" distros is best avoided by
sticking the a set of interoperable repositories (i.e.,
repositories that don't step on each other) with the largest
selection of packages.  It also helps if the repositories
maintain packaging standards to help minimize needless
dependencies. 

> The apt vs yum argument is not as important

Especially given the emergence of SmartPM which not only
makes the repository layout moot, but seems to best both in
dependency logic -- let alone comes with various interfaces,
including a GUI, as a standard part of the codebase.  As much
as people argue that APT-DPKG and YUM-RPM are "more native"
to Debian and Fedora bases, respectively, SmartPM seems to be
the "holy grail" of package management front-ends.

But no, no package management front-end has anything to do
with solving repository hell.

> as the quality of the repository and maintaining that
> quality. There are some excellent repositories for RPMS,
> but there problem is that they are not all mutually
> compatible -- fragmentation of repositories is a problem.

A major issue with the Fedora Project continues to be the
lack of coordination between repositories.  Although Fedora
Extras has put forth the manpower to take submissions, most
3rd party repositories (e.g., DAT, FreshRPMS, etc...) still
do not align themselves -- sans Livna.ORG (which is largely
run by several Fedora Extra contributors, and is more about
legally questionable things that can't go into Fedora
Extras).  But one could argue that the Fedora Project has
come a long way in 2 years.

The good news is that CentOS, a rebuild of RHEL, has built a
reputable set of additional packages -- from CentOS Plus
(replacement kernels, packages, etc...) to CentOS Extras.

But, again, the focus on RHEL, which rebuilds like CentOS are
limited to, is not the availability of packages, but static
design and SLAs.  Hence your issues with package availability
for RHEL or any rebuild.

> After looking at the huge Debian package repository,
> I see that it has the bulk of what I am looking for in
> applications -- and these are hit and miss in being
> supported by the RPM repositories.

The problem is that you were running a "static" distribution
built for SLAs, not package availability, in RHEL (or any
rebuild of it).  You need a project that is more fluid
"packages" distro such as the Fedora or Debian Projects.

BTW, in case you haven't heard, there is a Debian "Common"
release that is being finalized.  It, like RHEL based off of
Fedora Core (and Red Hat Linux prior), will be more static
"snapshot" designed for certifying select 3rd party
applications and Service Level Agreements (SLAs).

> I am contemplating switching to Debian because of this.
> But I notice that Debian does not support the evolution
> mail program.

???  Last time I used it, Evolution was included.  Is this no
longer the case?

> I do see some indication of getting it working with Debian,
> but it is unclear to me which way to go. If there is a way
> to convert my saved evolution mail to another mail program,
> I might consider switching mail programs.

Evolution can save mail to mbox, mdir and maildir.
Your contacts can be exported as vcard.
Your calendaring can be exported as vcalendar.

mbox is the most universally supported mail.
Almost every PIM supports vcard these days.
Unfortunately, vcalendar support varies.


-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)