On Wed, Sep 1, 2010 at 04:57, Karanbir Singh mail-lists@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.