On 16.07.2007 15:39, Joel Andres Granados wrote:
reference : BZ#246444
I have 1 of 2 choices: [...] Comments greatly appreciated.
The better place for this questions is epel-devel-list (CCed and reply to set), where this has been discussed already in the past days and likely will get discussed further. It's also a topic for tomorrows EPEL SIG meeting (20070718, #fedora-meeting, 17:00 UTC). Join us ;-)
BTW, I'd currently prefer to take the python-imaging from RHEL, lower the EVR (by using a "0." at the start of Release), and ship it in EPEL, so users of EL5Server have it available as well, and users of EL5Client or CentOS will get their normal package. Not ideal, but KISS and should work if nobody does stupid things.
CU knurd
P.S.: /me wonders if mailman will eat the follow-up to epel-devel-list@redhat.com
P.P.S.:/me bets it will
Thorsten Leemhuis wrote:
On 16.07.2007 15:39, Joel Andres Granados wrote:
reference : BZ#246444
I have 1 of 2 choices: [...] Comments greatly appreciated.
The better place for this questions is epel-devel-list (CCed and reply to set),
thx, Ill additionally subscribe to the list. ;)
where this has been discussed already in the past days and likely will get discussed further. It's also a topic for tomorrows EPEL SIG meeting (20070718, #fedora-meeting, 17:00 UTC). Join us ;-)
I most likely will join you.
BTW, I'd currently prefer to take the python-imaging from RHEL, lower the EVR (by using a "0." at the start of Release),
So if I understand you correctly you want to ship the 1.1.5 source with a 1.1.6-0.3 versioned rpm? IMHO, since this does not really break anything (1.1.6 being in RHEL5 Server) it would be much better to go with the policy of having source version and rpm version consistency than having the EPEL/el5 and RHEL5 consistency. I also consider this being a matter of opinion as both approaches would work in theory :)
and ship it in EPEL, so users of EL5Server have it available as well, and users of EL5Client or CentOS will get their normal package. Not ideal, but KISS and should work if nobody does stupid things.
FWIW, I think that shipping the 1.1.6 version to EPEL/el5 is more KISS than modifying the release bit.
CU knurd
P.S.: /me wonders if mailman will eat the follow-up to epel-devel-list@redhat.com
P.P.S.:/me bets it will
I'll check this out and see if mailman did something funny.
-- Fedora-maintainers mailing list Fedora-maintainers@redhat.com https://www.redhat.com/mailman/listinfo/fedora-maintainers
I am not on this list yet, please keep me in cc replies.
On Tue, 17 Jul 2007 07:05:00 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
BTW, I'd currently prefer to take the python-imaging from RHEL, lower the EVR (by using a "0." at the start of Release), and ship it in EPEL, so users of EL5Server have it available as well, and users of EL5Client or CentOS will get their normal package. Not ideal, but KISS and should work if nobody does stupid things.
Correct me if I'm wrong here, but aren't we supposed to /not/ be doing offerings like this? EPEL isn't supposed to be a way for RHEL customers to get around their subscriptions, and we shouldn't be taking packages from one channel and just offering them in EPEL so that the rest of the people can have them. That's a very easy way to get Red Hat to put as much roadblock in EPEL's way as possible.
That said, somebody really needs to verify what I was told earlier, which is customers of EL5Server can use RHN and subscribe to the Client channels and get the content. Perhaps not vice-versa, but in this case it should be enough. Before we go down the road of doom, lets verify whether or not 5Server customers can get access to python-imaging through RHN.
On 7/17/07, Jesse Keating jkeating@redhat.com wrote:
That said, somebody really needs to verify what I was told earlier, which is customers of EL5Server can use RHN and subscribe to the Client channels and get the content. Perhaps not vice-versa, but in this case it should be enough. Before we go down the road of doom, lets verify whether or not 5Server customers can get access to python-imaging through RHN.
I don't think this is true. I have RHEL-5Server (academic) entitlement, and I don't see "Client" listed anywhere in my list of available software channels. I only see:
# RHEL Virtualization (v. 5 for 32-bit x86) # RHEL Supplementary (v. 5 for 32-bit x86) # RHEL Hardware Certification (v. 5 for 32-bit x86) # RHEL FasTrack (v. 5 for 32-bit x86) # Red Hat Network Tools for RHEL Server (v.5 32-bit x86)
And "python-imaging" is definitely not available to me:
root@bakserv:[~]# yum list python-imaging Loading "rhnplugin" plugin Loading "installonlyn" plugin Setting up repositories rhel-i386-server-5 100% |=========================| 1.4 kB 00:00 Reading repository metadata in from local files Finished
The situation may be different for those who paid full enterprise price for RHEL entitlements, but that doesn't change the fact that unless EPEL provides "client" packages, I'll be left with broken repositories. I will note, that it makes that much harder for me to justify paying money to RH if I can have a better service using Centos+EPEL.
Regards,
On Tue, 17 Jul 2007 10:15:38 -0400 "Konstantin Ryabitsev" icon@fedoraproject.org wrote:
The situation may be different for those who paid full enterprise price for RHEL entitlements, but that doesn't change the fact that unless EPEL provides "client" packages, I'll be left with broken repositories. I will note, that it makes that much harder for me to justify paying money to RH if I can have a better service using Centos+EPEL.
Yes I know, and this is the exact problem I yelled at our RHEL pm about months ago, as well as other EPEL heads at the time. I forewarned that this was a problem that needed to be solved, and nobody listened.
I'll dig more on my side of things to find out the scoop of what all 5Server should have access to via RHN.
Jesse Keating wrote:
On Tue, 17 Jul 2007 10:15:38 -0400 "Konstantin Ryabitsev" icon@fedoraproject.org wrote:
The situation may be different for those who paid full enterprise price for RHEL entitlements, but that doesn't change the fact that unless EPEL provides "client" packages, I'll be left with broken repositories. I will note, that it makes that much harder for me to justify paying money to RH if I can have a better service using Centos+EPEL.
Yes I know, and this is the exact problem I yelled at our RHEL pm about months ago, as well as other EPEL heads at the time. I forewarned that this was a problem that needed to be solved, and nobody listened.
I'll dig more on my side of things to find out the scoop of what all 5Server should have access to via RHN.
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
As I understand it, If the main channel or child channels don't have the package a new channel must be acquired. I'll ask around the office.
The client packages are going to become available to all server customers as soon as the RHN profiles get updated. That takes some time as it is a major repull of data.
For python-imaging my proposal is to move it to the core server.
Did you open a ticket about this package with RH support?
Regards,
Daniel
On Tue, 2007-07-17 at 10:15 -0400, Konstantin Ryabitsev wrote:
On 7/17/07, Jesse Keating jkeating@redhat.com wrote:
That said, somebody really needs to verify what I was told earlier, which is customers of EL5Server can use RHN and subscribe to the Client channels and get the content. Perhaps not vice-versa, but in this case it should be enough. Before we go down the road of doom, lets verify whether or not 5Server customers can get access to python-imaging through RHN.
I don't think this is true. I have RHEL-5Server (academic) entitlement, and I don't see "Client" listed anywhere in my list of available software channels. I only see:
# RHEL Virtualization (v. 5 for 32-bit x86) # RHEL Supplementary (v. 5 for 32-bit x86) # RHEL Hardware Certification (v. 5 for 32-bit x86) # RHEL FasTrack (v. 5 for 32-bit x86) # Red Hat Network Tools for RHEL Server (v.5 32-bit x86)
And "python-imaging" is definitely not available to me:
root@bakserv:[~]# yum list python-imaging Loading "rhnplugin" plugin Loading "installonlyn" plugin Setting up repositories rhel-i386-server-5 100% |=========================| 1.4 kB 00:00 Reading repository metadata in from local files Finished
The situation may be different for those who paid full enterprise price for RHEL entitlements, but that doesn't change the fact that unless EPEL provides "client" packages, I'll be left with broken repositories. I will note, that it makes that much harder for me to justify paying money to RH if I can have a better service using Centos+EPEL.
Regards,
Daniel Riek wrote:
The client packages are going to become available to all server customers as soon as the RHN profiles get updated. That takes some time as it is a major repull of data.
For python-imaging my proposal is to move it to the core server.
Did you open a ticket about this package with RH support?
Regards,
Daniel
On Tue, 2007-07-17 at 10:15 -0400, Konstantin Ryabitsev wrote:
On 7/17/07, Jesse Keating jkeating@redhat.com wrote:
That said, somebody really needs to verify what I was told earlier, which is customers of EL5Server can use RHN and subscribe to the Client channels and get the content. Perhaps not vice-versa, but in this case it should be enough. Before we go down the road of doom, lets verify whether or not 5Server customers can get access to python-imaging through RHN.
I don't think this is true. I have RHEL-5Server (academic) entitlement, and I don't see "Client" listed anywhere in my list of available software channels. I only see:
# RHEL Virtualization (v. 5 for 32-bit x86) # RHEL Supplementary (v. 5 for 32-bit x86) # RHEL Hardware Certification (v. 5 for 32-bit x86) # RHEL FasTrack (v. 5 for 32-bit x86) # Red Hat Network Tools for RHEL Server (v.5 32-bit x86)
And "python-imaging" is definitely not available to me:
root@bakserv:[~]# yum list python-imaging Loading "rhnplugin" plugin Loading "installonlyn" plugin Setting up repositories rhel-i386-server-5 100% |=========================| 1.4 kB 00:00 Reading repository metadata in from local files Finished
The situation may be different for those who paid full enterprise price for RHEL entitlements, but that doesn't change the fact that unless EPEL provides "client" packages, I'll be left with broken repositories. I will note, that it makes that much harder for me to justify paying money to RH if I can have a better service using Centos+EPEL.
Regards,
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
Question: was the fact that python-imaging got introduced to RHELClient and not Server a conscious determination or was it a mistake? if it was a conscious determination, what are the policies that dictate when and how this occurs? and where can they be found?
Regards.
On Tue, 2007-07-17 at 17:01 +0200, Joel Andres Granados wrote:
Question: was the fact that python-imaging got introduced to RHELClient and not Server a conscious determination or was it a mistake? if it was a conscious determination, what are the policies that dictate when and how this occurs? and where can they be found?
I think it was a side effect of the decision to move whatever required it to the Client but not the core Server (need to review that). There is no publicly available policy document on this, but in general packages that are pulled in by another package, move to the repository of that other package. It also was a mistake because I could have forseen that sofware wants to use it.
Regards,
Daniel
Daniel Riek wrote:
On Tue, 2007-07-17 at 17:01 +0200, Joel Andres Granados wrote:
Question: was the fact that python-imaging got introduced to RHELClient and not Server a conscious determination or was it a mistake? if it was a conscious determination, what are the policies that dictate when and how this occurs? and where can they be found?
I think it was a side effect of the decision to move whatever required it to the Client but not the core Server (need to review that). There is no publicly available policy document on this, but in general packages that are pulled in by another package, move to the repository of that other package. It also was a mistake because I could have forseen that sofware wants to use it.
Regards,
I'm the maintainer in RHEL for this package. do I need some special considerations or do I just rebuild for 5.1? thx.
Daniel
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
You don't need to do anything. We just move it in the buildsystem. We can always move packages from a child repository (-channel) to the base.
If there are other issues, please contact me off-list.
Regards,
Daniel
On Tue, 2007-07-17 at 17:35 +0200, Joel Andres Granados wrote:
Daniel Riek wrote:
On Tue, 2007-07-17 at 17:01 +0200, Joel Andres Granados wrote:
Question: was the fact that python-imaging got introduced to RHELClient and not Server a conscious determination or was it a mistake? if it was a conscious determination, what are the policies that dictate when and how this occurs? and where can they be found?
I think it was a side effect of the decision to move whatever required it to the Client but not the core Server (need to review that). There is no publicly available policy document on this, but in general packages that are pulled in by another package, move to the repository of that other package. It also was a mistake because I could have forseen that sofware wants to use it.
Regards,
I'm the maintainer in RHEL for this package. do I need some special considerations or do I just rebuild for 5.1? thx.
Daniel
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On 7/17/07, Daniel Riek riek@redhat.com wrote:
The client packages are going to become available to all server customers as soon as the RHN profiles get updated. That takes some time as it is a major repull of data.
Ah, sweet! I knew there was a sane solution to this. :)
For python-imaging my proposal is to move it to the core server.
Did you open a ticket about this package with RH support?
No, it's not something that affects me directly. I'm interested purely because I was the one that requested that python-imaging be branched for EPEL, and hence was responsible for the creation of the situation.
Besides, I'm academic. We don't get support. ;)
Cheers,
On Tue, 2007-07-17 at 11:26 -0400, Konstantin Ryabitsev wrote: [...]
Did you open a ticket about this package with RH support?
No, it's not something that affects me directly. I'm interested purely because I was the one that requested that python-imaging be branched for EPEL, and hence was responsible for the creation of the situation.
Well, thanks then for finding the issue and bringing it forward. Without this discussion we would have not realized that we were causing frustration...
Besides, I'm academic. We don't get support. ;)
Oh, well ;-)
Regards,
Daniel
Cheers,
On 17.07.2007 16:51, Daniel Riek wrote:
The client packages are going to become available to all server customers as soon as the RHN profiles get updated. That takes some time as it is a major repull of data.
thx for your help Daniel.
CU knurd
On 7/17/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 17.07.2007 16:51, Daniel Riek wrote:
The client packages are going to become available to all server customers as soon as the RHN profiles get updated. That takes some time as it is a major repull of data.
thx for your help Daniel.
Yes thanks to all the RH people on this.. Longterm, there is going to be a mismatch between RHEL and CentOS/Scientific Linux offerings. As in, an EPEL package might need stuff from MultiOS or RHAPS (or whatever its future incarnation is) or etc etc etc. There should be a methodology for dealing with these packages or problems:
1) Should packages be built/included that can work with the lowest common denominator of channel offerings? [EG desktop or whatever is the smallest channel offering?]
2) If not, how do you offer packages that do not 'break' for people. If I do a yum install xyz and it includes something from outside of my 'Desktop' channel ... do I get a 'Dependencies not found. Please pony up more money.' message? Or do I get those dependencies via the .0 method
3) Other issues that my blood sugar cant think of at the moment.
Stephen John Smoogen wrote:
On 7/17/07, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 17.07.2007 16:51, Daniel Riek wrote:
The client packages are going to become available to all server customers as soon as the RHN profiles get updated. That takes some time as it is a major repull of data.
thx for your help Daniel.
Yes thanks to all the RH people on this.. Longterm, there is going to be a mismatch between RHEL and CentOS/Scientific Linux offerings. As in, an EPEL package might need stuff from MultiOS or RHAPS (or whatever its future incarnation is) or etc etc etc. There should be a methodology for dealing with these packages or problems:
- Should packages be built/included that can work with the lowest
common denominator of channel offerings? [EG desktop or whatever is the smallest channel offering?]
- If not, how do you offer packages that do not 'break' for people.
If I do a yum install xyz and it includes something from outside of my 'Desktop' channel ... do I get a 'Dependencies not found. Please pony up more money.' message? Or do I get those dependencies via the .0 method
- Other issues that my blood sugar cant think of at the moment.
3) What do you do when Red Hat introduces new packages into RHEL when those packages already exist in EPEL? These can happen during the regular major updates like 5.1 or 4.6. Prior information on what new packages goes into those updates are not always available publicly.
Rahul
epel-devel@lists.fedoraproject.org