"CMC" == Claire Connelly cmc@math.hmc.edu "AT" == Axel Thimm Axel.Thimm@ATrpms.net

CMC> From last week's steering committee meeting transcript, CMC> it sounds like the whole repotags issue appears to be CMC> moving ahead, which seems like a good step forward.

AT> You think so? After the repotag fiasco I went through a AT> lot of pain to strip them of, so the damage is done. Also AT> the issue showed the real weakness of repotags: It takes AT> just one non-conforming repo to kill them.

Well, based on the transcript from today's IRC meeting, I guess I totally misread things.

CMC> Can we look forward to better relations between EPEL and CMC> the other repos on other fronts as well?

AT> I really hope so, but adding repotags to epel will not AT> help anymore in this - it's too late, repotags are dead AT> and the pain has been inflicted, in fact for me the AT> revival of repotags would imply the same transition pain AT> again.

Obviously repotags are dead, but what about other forms of cooperation (if there are any)?

AT> We need much higher level manifests like for example

AT> http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration?act...

I thought this document was brilliant. Alas, it doesn't seem to be catching on.

From the sounds of things, EPEL is going in several directions that make it less than useful for our needs, which means that putting any work into it is going to be a waste of my time. Is there another list where the rest of the repository folks (CentOS, AT RPMS, RPM Forge, et al.) are going to get together so those of us giving up on EPEL can keep track of what's happening between them and maybe contribute there?

Thanks,

Claire

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

"CMC" == Claire Connelly cmc@math.hmc.edu "JS" == Jeff Sheltren sheltren@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@math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*