On Fri, 23 Jan 2009, Stephen John Smoogen wrote:
> Maybe we can't support each z-series of RHEL, but do we
really have because
> of that to explicitly break something then which would go smoothly by its
> own? It thought until now, we're contributors and try to enhance RHEL with
> EPEL if and wherever it is possible, but somehow I'm (nearly?) alone with
> this opinion on the list...
My opinion is that its broken, but I do not see a solution that we can
'afford' to make without completely re-engineering the project which I
am open to hearing how it can be done.
Now I don't care what happens with pexpect in EPEL any longer - drop it
when you're dropping the other packages that went into RHEL. If EPEL does
not want to keep the pexpect RPM package, then simply don't do it.
The EPEL package which a lot of RHEL users care about, is duplicity. That
was depending in the past on pexpect. In the future this will be no longer
case (thanks to duplicity upstream changing that - independent on the stuff
happened on this list), so there is and will be no broken dependency for
RHEL < 5.2 users when using duplicity.
Maybe Karsten is really doing something and stuff is not simply the same
for RHEL 5.4. Regarding the insane packaging of pexpect in RHEL 4.7+ and
RHEL 5.2+ I've made two bug reports which Karsten is also on Cc. Unluckily
I'm not expecting, that the insane Red Hat packaging of pexpect will ever
change - from Fedora view, we would consider the maintainer simply AWOL.