[CentOS-devel] Looking for input from EPEL
Stephen John Smoogen
smooge at gmail.com
Wed Sep 1 17:26:41 EDT 2010
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.
>> much as I would like to go with repotags.. that has been seen as a
> 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
More information about the CentOS-devel