pexepct is in RHEL and should be dropped from EPEL

[Robert Scheck]

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*).

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.

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.

If such things are not checked by the Red Hat downstream package maintainer
this is real lack of quality assurance and also absence of absolutely basic
RPM packaging knowledge.


Greetings,
  Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20090123/5249ef31/attachment.sig>