pexepct is in RHEL and should be dropped from EPEL

[Jeroen van Meeuwen]

Robert Scheck wrote:
> Hello Jeroen,
> 
> On Fri, 23 Jan 2009, Jeroen van Meeuwen wrote:
>> I would definitely say that since they're in the business of making  
>> customers happy, not us, part of that responsibility is bumping release  
>> numbers, searching for higher nevra and communication with the EPEL  
>> maintainers, so that their customers remain happy (rather then confused  
>> between RHEL and EPEL packages).
> 
> thank you. You're somehow the first guy on this thread being knowledged in
> basic things of packaging. I'm also a bit shocked, that such basics are not
> known to other packagers (aren't some of the people that have shown up here
> in the thread even provenpackagers? *shrug*).
> 

Not saying you are right or wrong or whether I agree or disagree with 
what you just said here, I really want to emphasize that EPEL seems to 
be "on it's own"; Red Hat GSS does not seem to concern itself with 
anything in or surrounding EPEL. While this is somewhat to be expected 
(we are just another third party repo), I'm sure we'll hear about it if 
and when we do override their packages. And, rather then playing the 
guilt-question, I'd like to explore opportunities to get this resolved.

Red Hat GSS obviously takes advantage with EPEL, as they can often just 
grab a package from EPEL X to be included in RHEL X.Y+1 whenever they 
feel like it. I'm pretty sure they put enough QA effort in on such 
package, but meanwhile they do not even bother to notify the current 
EPEL maintainer(s). I think making this a standard checklist item in 
their procedures should help. Even if just sending an (automated?) mail 
to <package>-owner at fedoraproject.org, saying "this package is now in the 
following branches/channels".

> There's a usual scenario: Customer is using RHEL 5.0, was installing the
> duplicity package from EPEL, thus pexpect from EPEL popped onto the system;
> then he updated to RHEL 5.1, everything fine. Then he updated to RHEL 5.2;
> pexpect from EPEL still remains and the pexpect from RHEL is ignored, as
> they've both the same (!) ENVRA. So the customer using EPEL before RHEL 5.2
> in this case is simply disadvantaged/aggrieved, because he never will get
> the pexpect package from RHEL without manual interaction.
> 

On the other end is the issue of EL "customers" still running 4.X or 5.Y 
and not upgrading. To maintain package foo in EPEL for 4.X or 5.Y (but 
not 4.X+1 or 5.Y+1), we'd need 4.X/5.Y specific branches. However, the 
amount of work involved, the infrastructure, the number of volunteers 
(or their time), and what-have-you, seems to not add up / be in balance 
in order for us to be able to do so.

Personally, I regret that, but I'm not complaining -complaining in my 
opinion doesn't help. Since I'd love to see these things resolved, I can 
only wait for us to start doing whatever it is we need to do in a manner 
that we all think is great and brings peace to the world and then put in 
some work to get it done.

> This is, why I said, Red Hat broke it, Red Hat has to fix it. EPEL cannot
> solve this in a perfect way. And if the customer is still on a RHEL 5.x.y
> (where x < 2) tree, he even can't install duplicity because of the missing
> dependency to pexpect; so lowering release from -1 to -0 is not all.
> 

I'm sorta curious how many EPEL users out there run into these kind of 
situations, and whether it's a real problem for them (or whether it's 
just annoying). Can we reach out to the EPEL users somehow?

Kind regards,

Jeroen van Meeuwen
-kanarip