FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 01-22-2009, 08:04 AM
David Juran
 
Default pexepct is in RHEL and should be dropped from EPEL

Hello.

Just noticed that pexpect is in RHEL (RHEL5 since 5.2 and RHEL4 since
4.7) and should therefore be dropped from EPEL.

--
David Juran
Sr. Consultant
Red Hat
+358-504-146348
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-22-2009, 08:41 AM
Robert Scheck
 
Default pexepct is in RHEL and should be dropped from EPEL

Hello David,

On Thu, 22 Jan 2009, David Juran wrote:
> Just noticed that pexpect is in RHEL (RHEL5 since 5.2 and RHEL4 since
> 4.7) and should therefore be dropped from EPEL.

nice, that somebody from the Red Hat fraction has been woken up, is Jim
Parsons alive? See: https://bugzilla.redhat.com/show_bug.cgi?id=452762

How do you expect that we perform the dropping? We can't remove branches
that already exist - spoken for CVS. And the pexpect package *has* to
remain in EPEL for users that did not upgrade to RHEL 5.2 (5.0.x, 5.1.x);
otherwise e.g. duplicity will get immediately unusable on such systems.

Of course I will avoid touching the pexpect that way, that maybe pexpect
from RHEL 5.2+/4.7+ gets obsoleted or older.

So, pexpect package MUST NOT removed ever from EPEL 4 and 5 as of legacy
support mentioned above - period!


Greetings,
Robert
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-22-2009, 03:23 PM
David Juran
 
Default pexepct is in RHEL and should be dropped from EPEL

On Thu, 2009-01-22 at 10:41 +0100, Robert Scheck wrote:

> How do you expect that we perform the dropping? We can't remove branches
> that already exist - spoken for CVS. And the pexpect package *has* to
> remain in EPEL for users that did not upgrade to RHEL 5.2 (5.0.x, 5.1.x);
> otherwise e.g. duplicity will get immediately unusable on such systems.

Since the version of the packages really is the same in both EPEL and
RHEL (pyexpect-2.3-1) I guess the proper thing to do would be to bump
the release number in RHEL. Or possibly the other way around, by
downgrading the EPEL versions to
pyexpect-2.3-0.5...

--
David Juran
Sr. Consultant
Red Hat
+358-504-146348
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-22-2009, 03:51 PM
Robert Scheck
 
Default pexepct is in RHEL and should be dropped from EPEL

On Thu, 22 Jan 2009, David Juran wrote:
> Since the version of the packages really is the same in both EPEL and
> RHEL (pyexpect-2.3-1) I guess the proper thing to do would be to bump
> the release number in RHEL. Or possibly the other way around, by
> downgrading the EPEL versions to pyexpect-2.3-0.5...

Well, I think the way how the package was stolen in EPEL and imported into
RHEL was done a way too silent and thus wrong. If Jim would have come up to
me as pexpect maintainer, we could have clarified that before and thus we
could have avoid the equivalent release number thing we now have. But does
Jim really exist? He didn't yet show up at this e-mails and didn't show any
reaction to the bug report...

Currently, it is not really possible to push an older version into the EPEL
repositiories without manual work, as the scripts allow only newer things -
Dennis, am I correct? I don't know, whether it's more easy for Red Hat to
cause a release number bump for pexpect.

As this mistake was caused by Red Hat, I don't see a good reason, why EPEL
shall fix this and take care of it. IMHO a good package maintainer does
such things and has a careful look around before acting, especially if the
package is stolen (IIRC even the %changelog wasn't changed) - the Red Hat
guy didn't do that until now.


Greetings,
Robert
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-22-2009, 05:26 PM
Rahul Sundaram
 
Default pexepct is in RHEL and should be dropped from EPEL

Robert Scheck wrote:


As this mistake was caused by Red Hat, I don't see a good reason, why EPEL
shall fix this and take care of it.


It must be fixed because, that is the EPEL policy regardless of the
history of the package.


IMHO a good package maintainer does

such things and has a careful look around before acting, especially if the
package is stolen (IIRC even the %changelog wasn't changed) - the Red Hat
guy didn't do that until now.


I agree on coordination however re-using a spec cannot be called
stealing by any means.


Rahul

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-22-2009, 06:32 PM
Patrice Dumas
 
Default pexepct is in RHEL and should be dropped from EPEL

On Thu, Jan 22, 2009 at 11:56:35PM +0530, Rahul Sundaram wrote:
>
> I agree on coordination however re-using a spec cannot be called
> stealing by any means.

I'd even say that if RHEL stole EPEL package each time when putting it
in RHEL there would be less upgrade issue. Of course, the least would
be to warn the EPEL maintainer.

--
Pat

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-22-2009, 07:25 PM
Rex Dieter
 
Default pexepct is in RHEL and should be dropped from EPEL

Robert Scheck wrote:

> Hello David,
>
> On Thu, 22 Jan 2009, David Juran wrote:
>> Just noticed that pexpect is in RHEL (RHEL5 since 5.2 and RHEL4 since
>> 4.7) and should therefore be dropped from EPEL.
>
> nice, that somebody from the Red Hat fraction has been woken up, is Jim
> Parsons alive? See: https://bugzilla.redhat.com/show_bug.cgi?id=452762
>
> How do you expect that we perform the dropping? We can't remove branches
> that already exist - spoken for CVS. And the pexpect package *has* to
> remain in EPEL for users that did not upgrade to RHEL 5.2

I thought EPEL only really supports the latest RHEL flavors anyway. At
least that was my impression from previous similar converations. Has
something changed?

-- Rex

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-22-2009, 07:31 PM
Stephen John Smoogen
 
Default pexepct is in RHEL and should be dropped from EPEL

On Thu, Jan 22, 2009 at 1:25 PM, Rex Dieter <rdieter@math.unl.edu> wrote:
> Robert Scheck wrote:
>
>> Hello David,
>>
>> On Thu, 22 Jan 2009, David Juran wrote:
>>> Just noticed that pexpect is in RHEL (RHEL5 since 5.2 and RHEL4 since
>>> 4.7) and should therefore be dropped from EPEL.
>>
>> nice, that somebody from the Red Hat fraction has been woken up, is Jim
>> Parsons alive? See: https://bugzilla.redhat.com/show_bug.cgi?id=452762
>>
>> How do you expect that we perform the dropping? We can't remove branches
>> that already exist - spoken for CVS. And the pexpect package *has* to
>> remain in EPEL for users that did not upgrade to RHEL 5.2
>
> I thought EPEL only really supports the latest RHEL flavors anyway. At
> least that was my impression from previous similar converations. Has
> something changed?

Currently that is the case. There is not enough infrastructure to do
multiple releases of EPEL for 4.x/5.x series.



--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-22-2009, 09:11 PM
Mike McGrath
 
Default pexepct is in RHEL and should be dropped from EPEL

On Thu, 22 Jan 2009, Robert Scheck wrote:

> On Thu, 22 Jan 2009, David Juran wrote:
> > Since the version of the packages really is the same in both EPEL and
> > RHEL (pyexpect-2.3-1) I guess the proper thing to do would be to bump
> > the release number in RHEL. Or possibly the other way around, by
> > downgrading the EPEL versions to pyexpect-2.3-0.5...
>
> Well, I think the way how the package was stolen in EPEL and imported into
> RHEL was done a way too silent and thus wrong. If Jim would have come up to
> me as pexpect maintainer, we could have clarified that before and thus we
> could have avoid the equivalent release number thing we now have. But does
> Jim really exist? He didn't yet show up at this e-mails and didn't show any
> reaction to the bug report...
>
> Currently, it is not really possible to push an older version into the EPEL
> repositiories without manual work, as the scripts allow only newer things -
> Dennis, am I correct? I don't know, whether it's more easy for Red Hat to
> cause a release number bump for pexpect.
>
> As this mistake was caused by Red Hat, I don't see a good reason, why EPEL
> shall fix this and take care of it. IMHO a good package maintainer does
> such things and has a careful look around before acting, especially if the
> package is stolen (IIRC even the %changelog wasn't changed) - the Red Hat
> guy didn't do that until now.
>

This is nice and all but EPEL is compatable with RHEL, not the other way
around. We, unfortunately, have a one way relationship with RHEL. They
decide what goes into RHEL, not us. It would be nice to have more open
communcation about these things (I hope that is coming in the future) but
still, they can decide whatever they want to.

-Mike

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-22-2009, 09:35 PM
Robert Scheck
 
Default pexepct is in RHEL and should be dropped from EPEL

On Thu, 22 Jan 2009, Mike McGrath wrote:
> This is nice and all but EPEL is compatable with RHEL, not the other way
> around. We, unfortunately, have a one way relationship with RHEL. They
> decide what goes into RHEL, not us. It would be nice to have more open
> communcation about these things (I hope that is coming in the future) but
> still, they can decide whatever they want to.

I am not willing to see e.g. duplicity on RHEL < 5.2 broken.

In fact, duplicity is used by RHEL 4 and 5 customers and in the past there
have been several e-mails from Red Hat supporters (or whoever these guys
working at Red Hat are) claiming if something has broken at their customers
machines. I don't want to see breakage again as we can avoid it here by not
dropping the package.

And I ever thought, EPEL is meant to be stable and reliable to Enterprise
customers (even if it isn't supported by Red Hat). If we now really go and
break things, we're getting just another fscked up repository out there...

I'm not questioning, that Red Hat decides what goes into RHEL, but if they
steal packages silently, that must be communicated and it has to be ensured
that upgrading from older versions doesn't break something everywhere (and
it is surely known to Red Hat, that e.g. duplicity from EPEL repository is
in use by RHEL customers).

What happend for pexpect is a lack of quality assurance at Red Hat and a
lack of quality caused by the pexpect downstream package maintainer on Red
Hat side, too.


Greetings,
Robert

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 07:44 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org