[CentOS-devel] Looking for input from EPEL

Wed Sep 1 21:26:41 UTC 2010
Stephen John Smoogen <smooge at gmail.com>

On Wed, Sep 1, 2010 at 04:57, Karanbir Singh <mail-lists at karan.org> wrote:
> On 08/31/2010 09:52 PM, Stephen John Smoogen wrote:
>> With the differences between EL-6 architectures we are finding that we
>> need to build things for PPC or i386 that Upstream x86_64 has.
> This isnt really new to EL6, we ran into this issue with EL5 as well and
> have decided to publish all rpms into the main single distro repo( os +
> updates ).
> Is there any reason why we should change that policy now ?

Well this was more aimed at EPEL than CentOS. With us building stuff
for PPC64 we end up building dependencies that mimic what is in TUV
and thus CentOS.

>> people not wanting to have a different RPM spec file from upstream we
>> will end up with an x86_64 package set too.. which as the good old Fat
>> Controller would say "causes confusion and delay". So in order to
>> satisfy various factions we are looking at add a COST to EPEL so that
>> it would be higher than the default 1000 (say 1100).
> Cost itself wont solve the problem, there would need to be a blacklist
> at the repo end to make sure that rpms are never published that have a
> higher EVR than whats in the main distro. Even if the pkg does not exit
> for the same arch upstrem.

Yes supposedly this can be done in our koji/bodhi now.

> Ofcourse, the fact that epel will end up rebuilding packages that are in
> rhel core is going to be an interesting twist - specially when pkg
> maintainers are different.

Yes.. the rule will be that those packages will be built only from
upstream sources with any trademarks 'ripped' out. Though I doubt any
of the packages we are dealing with have upstream trademarks
(perl-cpan-OMGitsfullofstars being the main culprit).

>> What I would like to know is if this would affect CentOS-6, SciLin-6
>> or other repos so that we can deal with it now versus later. [And as
> The only real issue would be when packages overlap, and what is the best
> way to address that is something that would need to be handled at the
> third party repo side of things ( so not Red Hat or CentOS ). We are
> already working towards having a public build queue that exposes a json
> interface, so automating stuff around that should not be hard for anyone.

Ah cool.

>> much as I would like to go with repotags.. that has been seen as a
>> non-starter.]
> Is'nt epel the only repo not using a repo specific tag ?

That I know of, yes. I am outvoted on this one though.. from as many
people outside of RH as inside.

Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines