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