[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Introduction of overlapping postfix26 package in EPEL-5?

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]