Update strategy

[C.M. Connelly]

"TL"  == Thorsten Leemhuis <fedora at leemhuis.info>
"SJS" == Stephen John Smoogen

    SJS> The early adopters wanted RHEL-5 with additional items
    SJS> and some level of replacement. They wanted the newest
    SJS> version of say moin, clustering application etc as they
    SJS> are usually wanting the best new experience for their
    SJS> 'customers'... but want more stability in the
    SJS> backend. Most are served by a Fedora or the Red Hat
    SJS> Global Desktop.. but may need a core set of items
    SJS> (glibc/kernel) stable for some programmatic reason

    TL> I'd say those people that only want some new apps and a
    TL> stable backend are best served with a local repo for the
    TL> apps they need in up2date version or other specific small
    TL> repos. They can use the Fedora packages as a base for it;
    TL> EPEL probably can't serve those people with todays tools
    TL> (yum and co), as each and everyone defines stable backend
    TL> differently.

That's about where we are right now.  We're running CentOS on
servers and workstations because it's easier to maintain a local
set of packages for one OS (although we're currently spread out
over 3 and 4, with 5 the obvious upgrade path for the summer).
Our users don't need the latest and greatest cutting-edge software
for most things, but it is important that some tools (math-related
applications, TeX system, Subversion, etc.) be very recent.

I do have my own local repo, mostly with packages from Fedora and
Dag's RPMforge, and I expected that I would have to maintain that
for some packages (including packages Fedora can't/won't touch
because of licensing or patent issues but the users demand;
packages for commercial software that we definitely couldn't
distribute; and packages for software that may not be
distributable because of its licensing terms).  But I was really
looking forward to having a single source for reasonably
up-to-date packages for the packages that are in Fedora.

From this discussion, it sounds like EPEL is targeting a
completely different set of end users.  Given the general
political nastiness surrounding the whole repotags issue, it also
sounds like there isn't much interest in cooperating with the
other third-party repos, which makes EPEL a lot less attractive.

I'm still watching, but I'm leaning toward deciding that EPEL
isn't going to be worth bothering with.

   Claire

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
  Claire Connelly                              cmc at math.hmc.edu 
  Systems Administrator                          (909) 621-8754   
  Department of Mathematics                 Harvey Mudd College
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20070522/8d866f69/attachment.sig>