On Apr 25, 2011, at 8:00 AM, Robert Scheck wrote:
Hello,
On Tue, 19 Apr 2011, BJ Dierkes wrote:
> Let me first introduce to you the IUS Community Project [1]. We started
> this project a year and a half ago to serve this type of situation. For
> those that are not familiar, we [IUS] maintain a repository of packages
> that explicitly replace packages in RHEL. So where EPEL is an 'add-on'
> repository and has strict policies about conflicting with RHEL... the IUS
> project has 'replacement' packages and also has strict policies:
I'm aware of IUS, but it's - sorry - yet another non-well known repository
with software for RHEL out there. In a security audit, some has already to
argue for EPEL, which usually works, because it's well known, but it starts
to get much harder with RPM Fusion already. So I don't want to imagine the
pain at an audit when IUS repository is used and in the end it's equivalent
to our internal company repository, but considered trustful, because it is
maintained in-house.
Understandable with regard to audits for sure. IUS is still young, but I hardly feel EPEL
is a better place for this type of package just because it would be easier for some to
pass a security audit based on it being more well known. Additionally, just for clarity
here, IUS has a lot of benefit over any other 'non-well known repo' in that its
sponsored by Rackspace and isn't just a repo maintained by some random person on the
weekend if/when they have time. Its a significant part of my teams $dayjob to ensure the
success of the project (as well as contributing to Fedora/EPEL).
All that said, I understand where you coming from.
> EPEL *adds* packages to RHEL... IUS *replaces* packages in RHEL. It
> keeps things a lot cleaner. When you try to mix the two into a single
> repo you increase complexity, as well as risk of unknown
> incompatibilities and issues.
Your argumentation still leaves the same risk to users if you enable EPEL
and IUS at the same time, so I don't see any benefit of this argumentation.
Correct, but at that point the potentially negative affects above then only affect users
of the separate repo (like IUS), and not all EPEL users (including those they have no
knowledge of the additional packages). Meaning, you'd only incur the added
risks/headache/issues/etc when subscribing to the additional repo and not just for
subscribing to EPEL. If you look at it this way, the majority of EPEL users are looking
for extra packages that they can't find in RHEL... where as all users of IUS (or
similar repo) are looking for newer replacement packages that currently suck in RHEL. It
is a pretty significant difference in audience needs. Extra packages vs. replacement
packages.
On Apr 20, 2011, at 10:06 AM, Dodji Seketeli wrote:
Thank you for bringing this up. As was not aware of IUS myself and I
am
glad to learn about it. I have one question though. Why can't IUS be a
Fedora branch, like EPEL? Both would be separate, but would still
leverage the (IMHO) wonderful Fedora infrastructure and mindshare.
We did have that very discussion in #fedora-meeting over a year ago, and at the time it
was decided that... EPEL itself has enough challenges in packaging and maintaining itself
that adding another repo was just not in the cards. Ultimately we decided any packagers
interested should participate in IUS and that merging IUS under Fedora Project wasn't
feasible at the time.
We [IUS] are certainly open to talks regarding this topic of having an 'IUS' repo
under Fedora (that sits next to EPEL)... which I think is a better conversation than
allowing IUS type packages in EPEL. Perhaps a topic for next epel meeting. My only
concern with that is... IUS has a pretty niche audience, and a very specific purpose in
the grand scheme of things. Fedora/EPEL would really need to weight the pros and cons on
whether it makes sense to go down that path or not.
---
derks