Results of LinuxTag Meetings?

[C.M. Connelly]

"CMC" == Claire Connelly <cmc at math.hmc.edu>
"JS"  == Jeff Sheltren <sheltren at cs.ucsb.edu>

    CMC> From the sounds of things, EPEL is going in several
    CMC> directions that make it less than useful for our needs,

    JS> [...] out of curiosity, what are your needs?  ie. What
    JS> would you like to see from an Enterprise package repo?

We (the math department at Harvey Mudd College) have around fifty
Linux systems, including faculty and staff desktops and laptops; a
couple of labs used for research and teaching; and various
servers, including a 16-core parallel machine and a small Beowulf
cluster.  (At the moment, these all run various releases of
CentOS, mostly 3, although I'm hoping to get everything moved up
to CentOS 5 by the start of the fall semester.)  We're also the
vanguard department on the Linux front, so some of what we learn
feeds back into other departments, academic computing, and so on.


Given that RHEL, and, thus, CentOS, is a bit stripped down, I have
to obtain and install additional software to provide things that
we need (e.g., mathematical software used for teaching or
research), things that are really nice to have (e.g., a
near-cutting-edge TeX system, nice print dialogs), and things that
people insist on having (e.g., the ability to watch DVDs or listen
to MP3s on their desktop or laptop machines; Flash; Adobe's awful
Reader).  Altogether, we have around 300 locally built packages
per release, per architecture.

Most of this additional software was already packaged by someone,
and so I have been able to rebuild packages from Fedora or other
repos (thanks, Dag!).  Some of it, though, isn't packaged at all,
and some of that will probably never show up in some repos because
of licensing issues (or the lack of clear licenses, in the case of
some of the weirder math software I've dealt with).

Because much of this software is already packaged, having a single
repo that contained well-packaged versions would be great.  Having
some level of quality assurance is a huge plus, along with active
maintainers and a bug-tracking system.  Being able to track stable
but recent packages would also be cool.  And not having to build
or rebuild all these packages myself would, of course, be the
best.


When I first heard about EPEL, I thought that it sounded like it
would be able to supply all the packages I've been rebuilding from
Fedora.  Dag's and Axel's involvement made me hope that I could
supplement EPEL's packages with additional packages from RPMForge,
ATrpms, and other repos.  I would still have to build or rebuild
some things myself, but I hoped that I could eliminate most of
that work and be able to concentrate on the software that wasn't
packaged (and, for the subset of that material that could be
distributed, maybe even get those packages added to Fedora (and
thus EPEL) so that the work I put in could be shared by others).

But over time it seems like the people running the EPEL SIG are
very much committed to the Fedora way of doing things, to the
point of not being interested in cooperation with other
third-party repos.  Decisions are made within a bureaucratic
framework that may or may not represent the actual views of any
end users.[*]  Even more recently, it has become clear that the
EPEL folks are interested in maintaining their rebuilt Fedora
packages for timeframes similar to or identical to those of the
upstream enterprise-Linux distribution, rather than tracking
current releases.


At this point, I should probably mention that I don't think that
there's anything fundamentally wrong with any of those attitudes
or decisions.

While some of us were hoping that EPEL would be something other
than what it is, EPEL can be whatever its participants want it to
be.  Nothing says that EPEL has to be interoperable with anything
else -- they're perfectly entitled to say that their package pool
is the most complete and that they don't care about packages
outside that pool.  

Similarly, I can see some use cases where having ``extra''
packages that are maintained for five or seven years without
updates would be a desirable thing, although that isn't the best
choice for *my* use cases (at least for the workstation side of
things).

So I'm sorry to see that EPEL won't be a solution for me, and that
I will have to look elsewhere, or maybe, at worst, continue to do
what I've been doing all along.  And I'm sorry that EPEL has
decided that cooperating with the existing non-Fedora community is
not a goal that they want to pursue, as cooperation could have
dramatically reduced the amount of duplicated effort in
maintaining separate spec files, build systems, and so forth.

On the positive side, EPEL's choices and the discussions that have
resulted have probably helped to make some issues clearer to the
rest of the folks doing packaging, and those insights might help
those folks work better together to provide alternatives to EPEL
that might be more suited for other use cases.


Finally, if I'm wrong about one or more of my assertions about
EPEL's goals, I apologize and expect to be corrected.  My take
here is based on my readings of the discussions on the mailing
list and the transcripts of the steering committee meetings from
IRC; there may well be additional information I'm not aware of,
and I may be misreading some of the information available to me.

   Claire

[*] As EPEL hasn't quite gotten off the ground, technically I
    suppose there aren't any end users, yet.  But as a potential
    end-user, I know that the views of the steering committee
    don't correspond to my own.

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
  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/20070615/8ec82247/attachment.sig>