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-23-2009, 01:18 PM
Jussi Lehtola
 
Default pexepct is in RHEL and should be dropped from EPEL

On Fri, 2009-01-23 at 14:55 +0100, Robert Scheck wrote:
> On Fri, 23 Jan 2009, Rahul Sundaram wrote:
> > It would be good to document best practises when spec files are reused
> > in RHEL as is going to happen repeatedly so that both sides understand
> > what is to be done. Someone interested in not seeing things like this
> > should volunteer.
>
> Best practise is, if packagers would know, how packaging and ENVRA works -
> which seems not known to all packagers (independent whether Fedora or Red
> Hat at this case).
>
> My previous e-mail explains correct, why not bumping release of ENVRA is
> broken in such a case (which also would automagically cause %changelog to
> get silent rpmlint) and why it has to be fixed by Red Hat and why we at
> EPEL can't fix or solve it completely. So if somebody does not understand
> that, he/she shouldn't be a RPM packager at all, sorry.

I agree completely.

What should be done now is an increase of the release version in RHEL
( / CentOS), in order to get all installations from EPEL to update to
the Red Hat version.

What is a completely different question, however, is what to do with the
packages in EPEL. If the release in RHEL is incremented, and the package
is updated in EPEL afterwards to a higher EVR, the RHEL version will be
replaced with the EPEL version.

As a EPEL package maintainer, branching versions for different RHEL
releases (Updates) would be a humongous task, as some components need
special tweaks to work. Also, running an old release poses a security
threat.

Overlapping packages should be removed from EPEL, once a higher EVR is
available in RHEL. We shouldn't even think about people who don't want
to update to the newest RHEL release; if they need something from EPEL,
they can compile the srpms theirself.
--
Jussi Lehtola <jussi.lehtola@iki.fi>

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-23-2009, 02:01 PM
Jeroen van Meeuwen
 
Default pexepct is in RHEL and should be dropped from EPEL

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@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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-23-2009, 02:42 PM
Karsten Wade
 
Default pexepct is in RHEL and should be dropped from EPEL

On Thu, Jan 22, 2009 at 04:20:50PM -0700, Stephen John Smoogen wrote:

>
> However, in the end.. this is yet again poor customer relations where
> the customer is the contributor who is doing a lot of the work for Red
> Hat. It has made you pissed and will become one of those things that
> people point to of why Red Hat is a pot calling the kettle black about
> licenses etc.
>
> While I don't think this raises to the level of the Novell iFolder
> debacle it is time to see what RH community people (*cough* Greg
> DeKoenigsberg *cough*) can do within Red Hat to help better make these
> transitions.

Actually, that's me. After this happened for 5.1, I was the one who
said I'd find someone to make sure it didn't happen again. I thought
I did. Then it happened again in 5.2, and I said the same thing. I
thought it was taken care of that time. Now it happened again in 5.3.

Folks, I'm really sorry we're still in this state. It is truly not
due to incompetence or malice; it's simply a lack of policy and
procedure, mostly on the RHEL side. The repeated mistake is
disrespectful of the hard work happening in EPEL.

I'd appreciate another chance to make this right so it doesn't happen
again. I'm glad that those affected made more noise this time, it
should help make it clear there really is a problem.

- Karsten
--
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-23-2009, 02:53 PM
Karsten Wade
 
Default pexepct is in RHEL and should be dropped from EPEL

On Fri, Jan 23, 2009 at 11:56:52AM +0100, Jeroen van Meeuwen wrote:

> I also think it's a reasonable request to make, but I'm sure this has
> been raised before... Have we ever actually ask them? If yes, what did
> they respond?

After this happened in 5.1, I worked on something, but obviously what
was put in place then didn't stick. After it happened again in 5.2, I
failed to wield the cluestick widely enough to make sure it wouldn't
happen again.

The idea was generally approved, afaik -- no one in the RHEL
organization is deliberately keeping information from EPEL or the
maintainers. There is no communication procedure in place for
migrating packages from EPEL. Similarly, the opposite is true -- if a
RHEL point release drops a package, EPEL is not informed so that
someone has the option to pick up the orphaned pacakge.

I'll do my best from here to get a procedure in place soonest so we
have lots of advance notice next time ...

- Karsten
--
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-23-2009, 05:35 PM
Rahul Sundaram
 
Default pexepct is in RHEL and should be dropped from EPEL

Jeroen van Meeuwen wrote:



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


You are blaming the wrong people. GSS is just support people. They don't
involve themselves with maintaining packages or QA.


Rahul

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

2009/1/23 Robert Scheck <robert@fedoraproject.org>:
> 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*).

Thankyou for your insults and innuendo. If this is how you regularly
express yourself to humans I can see why you are not getting very far
in your end of the discussion. I think everyone who has responded is
quite versed in packages. However, your argument was not about that..
your phrasing was about stealing your intellectual property.

Did Red Hat not do what is proper packaging, yes clearly.

Did they have to? I do not see anything in the MIT or Fedora CLA that
says they needed to do so. And so the breakdown is that there are not
clearly documented processes on that part of the transaction into the
black-box.



--
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-23-2009, 07:00 PM
Robert Scheck
 
Default pexepct is in RHEL and should be dropped from EPEL

On Fri, 23 Jan 2009, Jeroen van Meeuwen wrote:
> Does this go to branching for minor RHEL releases? If so, I think the
> topic was raised before and considered to be way too much work for the
> small group of people that make up EPEL's core-maintenance team.

Yes, I've gotten this and can understand that as well.

But my question, I handed out to Mike before as well, didn't get still not
answered until now: Why do we _explicitly_ want to _break_ in EPEL what is
working and good enough since RHEL 5.0? Please show me the reason why we
actually really need to remove it.

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

EPEL is Extra Packages for Enterprise Linux, right? There are the words and
phrases "Extra Packages" and "Enterprise". Enterprise implicits IMHO, that
nothing breaks, everything goes smoothly; "Extra Packages" makes expection
to users of additional packages. Our current plan with removing packages in
EPEL that got obsoleted due imports into RHEL (instead of just freezing the
obsoleted EPEL packagesthem) has for me just less relationship with Extra
Packages for Enterprise Linux.


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

2009/1/23 Robert Scheck <robert@fedoraproject.org>:
> On Fri, 23 Jan 2009, Jeroen van Meeuwen wrote:
>> Does this go to branching for minor RHEL releases? If so, I think the
>> topic was raised before and considered to be way too much work for the
>> small group of people that make up EPEL's core-maintenance team.
>
> Yes, I've gotten this and can understand that as well.
>
> But my question, I handed out to Mike before as well, didn't get still not
> answered until now: Why do we _explicitly_ want to _break_ in EPEL what is
> working and good enough since RHEL 5.0? Please show me the reason why we
> actually really need to remove it.

EPEL is only meant to work with the latest RHEL tree (eg the latest Y
branch... ). This is a liability in how the system was set up but a
boon in how much complexity we could handle when setting it up. I
would love to be able to handle 5.x trees but what happens when the
newest pexpect comes out now... and you update. The 5.0 person is
happy because they got an update.. the 5.2 person has problems because
it doesn't match what they are expecting from RHN... eg we have broken
their assumption. And yes this sucks... but unless we are not upstream
for RHEL. We are a side-stream, and have to deal with the overflows
and erosion from the bigger river next to us.

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

> EPEL is Extra Packages for Enterprise Linux, right? There are the words and
> phrases "Extra Packages" and "Enterprise". Enterprise implicits IMHO, that
> nothing breaks, everything goes smoothly; "Extra Packages" makes expection
> to users of additional packages. Our current plan with removing packages in
> EPEL that got obsoleted due imports into RHEL (instead of just freezing the
> obsoleted EPEL packagesthem) has for me just less relationship with Extra
> Packages for Enterprise Linux.
>
>
> Greetings,
> Robert
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>
>



--
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-25-2009, 10:16 AM
Jeroen van Meeuwen
 
Default pexepct is in RHEL and should be dropped from EPEL

Rahul Sundaram wrote:

Jeroen van Meeuwen wrote:



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


You are blaming the wrong people. GSS is just support people. They don't
involve themselves with maintaining packages or QA.




Again, you only point out the wrong, not the right. Whoever it is or
whatever the department is called, it's @redhat.com. GSS has the most
benefit from getting it right, because they answer the phone when a
customer is confused having packages from EPEL that are in RHEL. I think
the message I wanted to send out was clear enough on it's own,
regardless of getting all the acronyms and departments right.


-Jeroen

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

Jeroen van Meeuwen wrote:


Whoever it is or
whatever the department is called, it's @redhat.com.


I don't think blaming the wrong department is a good idea however.

GSS has the most
benefit from getting it right, because they answer the phone when a
customer is confused having packages from EPEL that are in RHEL.


If this is the goal, it would be very useful to add the information on
how to differentiate between EPEL and RHEL to the EPEL wiki pages.


I think
the message I wanted to send out was clear enough on it's own,
regardless of getting all the acronyms and departments right.


Perhaps it is but it is important to correct it for the record. If you
don't want it directed at specific departments, just don't use the
acronyms. GSS stands for Global Support Services.


Rahul

_______________________________________________
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 03:58 PM.

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