[Spacewalk-devel] Re: Supporting other repositories.

[Michael DeHaan]

Stephen John Smoogen wrote:
> On Fri, Nov 7, 2008 at 12:55 PM, Dennis Gilmore <dennis at ausil.us> wrote:
>   
>> On Friday 07 November 2008 12:10:08 pm Stephen John Smoogen wrote:
>>     
>>> Ok loaded term but I was wondering if we could work with spacewalk,
>>> ipa, ds, etc to support their work by including at least a
>>> spacewalk-release or similar item. This would allow us to 'test' the
>>> waters of working closer with the other layered upstreams. Basically
>>> instead of having to hunt around for every different repository, we
>>> work with the upstream project ot have a signed release that works
>>> with the EPEL releases.
>>>
>>> Anyway.. back to dealing with local stuff.. I figured I should fire it
>>> off before I forget.
>>>       
>> Other than completely violating fedora's guidelines that EPEL is subject to.
>> I don't think its a good idea. It makes it too easy to not do the work needed
>> to get things into fedora/EPEL
>>
>>     
>
> The issue I am trying to deal with is several issues
>
> 1) we have RH-upstream-product-0.X needing something that RHEL-4/5 do
> not ship in apache etc Its going to happen because thats just how
> software projects go.
>   

I think we need to take a big heavy stick to those projects.

As much as I'd love Python 2.5 on RHEL 4 :)


> 2) we have stuff in EPEL that would replace a layered product. I mean
> if we put spacewalk in and it replaces something from
> RHN-supported-product. I really am not worried about sales.. someone's
> going to make rebuilds available somewhere but I am trying to work out
> a way that someone is not going to clobber themselves by having a RH
> product and enabling EPEL on the box.
>   

Mutual conflicts: tags should be sufficient.

> 3) product timeline does not match up with EPEL timeline. This happens
> a lot with the cobbler/koan/func stuff where they are implementing
> fixes but I could see it happening in say IPA etc. where they have a
> midmonth release or 'just-a-bugfix' upgrade.
>
>
>   

This is a consequence where it's important for products to target a 
"version ____ or later" API
and be tolerant about what to do when applications are missing 
features.   Applications must also maintain
stable APIs that continue to work.

I encounter some of this with libvirt being more capable on newer 
platforms but in all actuality it's not a
big problem.

Generally our strategy to do this is web services, and applications 
should support a method that returns the versions
of their API.   For applications that are more tightly integrated 
they'll have to make appropriate workarounds.

It is true that EPEL moves too slowly to get bugfixes out, though this 
can be countered by pointing
folks at EPEL testing until some day where that could hopefully be run 
more frequently and under Bohdi.

Needless to say, apps like Cobbler and Func are closely related to the 
Spacewalk team here, so I don't really
see it being a problem with having different priorities.   Making 
Spacewalk successful is definitely a major
priority.



>   
>> fedora-ds is in fedora I suggest that you ask richm to build fedora-ds into
>> EPEL. freeipa is in fedora also.  we should talk with rcrit to get freeipa
>> branched and built for EPEL  it will require fedora-ds to be there first.
>>     

++