I'm trying to build a package (ocaml-libvirt) for EPEL 5. Unfortunately it depends on libvirt >= 0.2.1. The version of libvirt on the plague build server seems to be libvirt 0.1.8 (ie. the version which shipped with RHEL 5 GA). RHEL 5.1 ships with libvirt 0.3.3, so that would be OK.
Is there anything I can do to build against the newer libvirt? Or is it just a matter of waiting until the RHEL 5.1 RPMs become available (and if that is the case, what is the likely timeline for that?)
Thanks,
Rich.
On 08.11.2007 15:52, Richard W.M. Jones wrote:
I'm trying to build a package (ocaml-libvirt) for EPEL 5. Unfortunately it depends on libvirt >= 0.2.1. The version of libvirt on the plague build server seems to be libvirt 0.1.8 (ie. the version which shipped with RHEL 5 GA). RHEL 5.1 ships with libvirt 0.3.3, so that would be OK.
Is there anything I can do to build against the newer libvirt? Or is it just a matter of waiting until the RHEL 5.1 RPMs become available (and if that is the case, what is the likely timeline for that?)
Well, we need to put some thoughts into this -- if we for example start building packages that require the newer libvirt today then users of CentOS 5.0 (5.1 is not released yet) and those still on RHEL 5.0.x would run into dependency issues when using EPEL. We should try hard to avoid that. That's why I suggested to keep "5.0" directories around for some weeks months -- but the idea was not that welcomed afaics...
Opinions?
Cu knurd
On Thu, 08 Nov 2007 20:18:55 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Well, we need to put some thoughts into this -- if we for example start building packages that require the newer libvirt today then users of CentOS 5.0 (5.1 is not released yet) and those still on RHEL 5.0.x would run into dependency issues when using EPEL. We should try hard to avoid that. That's why I suggested to keep "5.0" directories around for some weeks months -- but the idea was not that welcomed afaics...
5.0.x doesn't exist. 5.1.z will exist, for a period of time up to the release of 5.4 I think, or 5.5.
On Nov 8, 2007 12:22 PM, Jesse Keating jkeating@redhat.com wrote:
On Thu, 08 Nov 2007 20:18:55 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Well, we need to put some thoughts into this -- if we for example start building packages that require the newer libvirt today then users of CentOS 5.0 (5.1 is not released yet) and those still on RHEL 5.0.x would run into dependency issues when using EPEL. We should try hard to avoid that. That's why I suggested to keep "5.0" directories around for some weeks months -- but the idea was not that welcomed afaics...
5.0.x doesn't exist. 5.1.z will exist, for a period of time up to the release of 5.4 I think, or 5.5.
<grumpy id="old sys-admin"> So Red Hat didnt go with a 5.0.x? I am so glad they communicated that with a customer who banked on using it. At this point is there any assurance that 5.1.x will really exist? </grumpy>
On Thu, 8 Nov 2007 12:59:35 -0700 "Stephen John Smoogen" smooge@gmail.com wrote:
<grumpy id="old sys-admin"> So Red Hat didnt go with a 5.0.x? I am so glad they communicated that with a customer who banked on using it. At this point is there any assurance that 5.1.x will really exist? </grumpy>
Can you show me any official documentation or advertisement that states there will be a z-stream for 5.0 customers? There wasn't even an RHN channel for them to subscribe to.
On Nov 8, 2007 1:46 PM, Jesse Keating jkeating@redhat.com wrote:
On Thu, 8 Nov 2007 12:59:35 -0700 "Stephen John Smoogen" smooge@gmail.com wrote:
<grumpy id="old sys-admin"> So Red Hat didnt go with a 5.0.x? I am so glad they communicated that with a customer who banked on using it. At this point is there any assurance that 5.1.x will really exist? </grumpy>
Can you show me any official documentation or advertisement that states there will be a z-stream for 5.0 customers? There wasn't even an RHN channel for them to subscribe to.
I have to remember what sales people do not count... well that makes life easier in that I can just say "screw that until 5.1.z appears on RHN someday"
On 08.11.2007 20:22, Jesse Keating wrote:
On Thu, 08 Nov 2007 20:18:55 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Well, we need to put some thoughts into this -- if we for example start building packages that require the newer libvirt today then users of CentOS 5.0 (5.1 is not released yet) and those still on RHEL 5.0.x would run into dependency issues when using EPEL. We should try hard to avoid that. That's why I suggested to keep "5.0" directories around for some weeks months -- but the idea was not that welcomed afaics...
5.0.x doesn't exist. 5.1.z will exist, for a period of time up to the release of 5.4 I think, or 5.5.
Thx for the hint.
But well, the problem round about stays the same until CentOS (and other clones) ship 5.1. And we run into the same problem again for 5.1.z once 5.2 ships.
Cu knurd
On Nov 8, 2007 1:07 PM, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 08.11.2007 20:22, Jesse Keating wrote:
On Thu, 08 Nov 2007 20:18:55 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Well, we need to put some thoughts into this -- if we for example start building packages that require the newer libvirt today then users of CentOS 5.0 (5.1 is not released yet) and those still on RHEL 5.0.x would run into dependency issues when using EPEL. We should try hard to avoid that. That's why I suggested to keep "5.0" directories around for some weeks months -- but the idea was not that welcomed afaics...
5.0.x doesn't exist. 5.1.z will exist, for a period of time up to the release of 5.4 I think, or 5.5.
Thx for the hint.
But well, the problem round about stays the same until CentOS (and other clones) ship 5.1. And we run into the same problem again for 5.1.z once 5.2 ships.
May I suggest repotags or using CentOS as the build system :).
EPEL5.0.0 would be a good fix :).
There I have fulfilled my monthly trolling requirements.
On Thu, 08 Nov 2007 21:07:37 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Thx for the hint.
But well, the problem round about stays the same until CentOS (and other clones) ship 5.1. And we run into the same problem again for 5.1.z once 5.2 ships.
IMHO EPEL can make a decision to not support the z-stream. EPEL repos are designed to work with the most recently released RHEL Update. (or some wording that makes sense)
On 08.11.2007 21:50, Jesse Keating wrote:
On Thu, 08 Nov 2007 21:07:37 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Thx for the hint.
But well, the problem round about stays the same until CentOS (and other clones) ship 5.1. And we run into the same problem again for 5.1.z once 5.2 ships.
IMHO EPEL can make a decision to not support the z-stream.
Yeah, but I remember at least two people talked to me that would like to give people some weeks of flexibility before we indirectly force them to update. As simple 'cp -al 5 5.0; echo "this is unsupported" > 5.0/BIG_FAT_WARNING ; sleep 6w; rm -rf 5.0" could solve that.
But yeah, I actually tend to agree.
EPEL repos are designed to work with the most recently released RHEL Update. (or some wording that makes sense)
Which still does not solve the problem that started this thread...
CU knurd
On Thu, 08 Nov 2007 22:08:10 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Which still does not solve the problem that started this thread...
Correct. To solve the problem at the start of this thread, perhaps it would make sense to pre-populate the buildsystem with the next point release bits at the same time they're being staged for release, or close to it, so that EPEL can on the same day of a point release claim that they support that release. Just takes more cooperation between EPEL leaders and Red Hat.
On 08.11.2007 22:22, Jesse Keating wrote:
On Thu, 08 Nov 2007 22:08:10 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Which still does not solve the problem that started this thread...
Correct. To solve the problem at the start of this thread, perhaps it would make sense to pre-populate the buildsystem with the next point release bits at the same time they're being staged for release, or close to it, so that EPEL can on the same day of a point release claim that they support that release. Just takes more cooperation between EPEL leaders and Red Hat.
And excludes all those contributers and users that don't have a RHEL license, as the resulting bits might lead to broken deps when one runs "yum update" on a CentOS machine right now (¹) with EPEL which depends on a lib that is shipped in the newly released RHEL update. Seems that's the case in the mail that started this thread.
That would be totally unacceptable IMHO.
Cu knurd
(¹) -- e.g. before CentOS 5.1 is available
On Nov 8, 2007 4:39 PM, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 08.11.2007 22:22, Jesse Keating wrote:
On Thu, 08 Nov 2007 22:08:10 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Which still does not solve the problem that started this thread...
Correct. To solve the problem at the start of this thread, perhaps it would make sense to pre-populate the buildsystem with the next point release bits at the same time they're being staged for release, or close to it, so that EPEL can on the same day of a point release claim that they support that release. Just takes more cooperation between EPEL leaders and Red Hat.
And excludes all those contributers and users that don't have a RHEL license, as the resulting bits might lead to broken deps when one runs "yum update" on a CentOS machine right now (¹) with EPEL which depends on a lib that is shipped in the newly released RHEL update. Seems that's the case in the mail that started this thread.
That would be totally unacceptable IMHO.
So... users that DO have a RHEL license will have to wait for CentOS devels to do their thing before they can get new packages? What about Scientific Linux or other RHEL clones? Do those users have to wait for all the clones?
On Nov 8, 2007 3:27 PM, Kyle Gonzales kyle.gonzales@gmail.com wrote:
On Nov 8, 2007 4:39 PM, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 08.11.2007 22:22, Jesse Keating wrote:
On Thu, 08 Nov 2007 22:08:10 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Which still does not solve the problem that started this thread...
Correct. To solve the problem at the start of this thread, perhaps it would make sense to pre-populate the buildsystem with the next point release bits at the same time they're being staged for release, or close to it, so that EPEL can on the same day of a point release claim that they support that release. Just takes more cooperation between EPEL leaders and Red Hat.
And excludes all those contributers and users that don't have a RHEL license, as the resulting bits might lead to broken deps when one runs "yum update" on a CentOS machine right now (¹) with EPEL which depends on a lib that is shipped in the newly released RHEL update. Seems that's the case in the mail that started this thread.
That would be totally unacceptable IMHO.
So... users that DO have a RHEL license will have to wait for CentOS devels to do their thing before they can get new packages? What about Scientific Linux or other RHEL clones? Do those users have to wait for all the clones?
Well someone is going to be broke. The issue is finding out what percentage of people will be broken the longest... and upsetting them :)
On Nov 8, 2007 5:36 PM, Stephen John Smoogen smooge@gmail.com wrote:
On Nov 8, 2007 3:27 PM, Kyle Gonzales kyle.gonzales@gmail.com wrote:
On Nov 8, 2007 4:39 PM, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 08.11.2007 22:22, Jesse Keating wrote:
On Thu, 08 Nov 2007 22:08:10 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Which still does not solve the problem that started this thread...
Correct. To solve the problem at the start of this thread, perhaps it would make sense to pre-populate the buildsystem with the next point release bits at the same time they're being staged for release, or close to it, so that EPEL can on the same day of a point release claim that they support that release. Just takes more cooperation between EPEL leaders and Red Hat.
And excludes all those contributers and users that don't have a RHEL license, as the resulting bits might lead to broken deps when one runs "yum update" on a CentOS machine right now (¹) with EPEL which depends on a lib that is shipped in the newly released RHEL update. Seems that's the case in the mail that started this thread.
That would be totally unacceptable IMHO.
So... users that DO have a RHEL license will have to wait for CentOS devels to do their thing before they can get new packages? What about Scientific Linux or other RHEL clones? Do those users have to wait for all the clones?
Well someone is going to be broke. The issue is finding out what percentage of people will be broken the longest... and upsetting them :)
Ha! True that.
On 08.11.2007 23:27, Kyle Gonzales wrote:
On Nov 8, 2007 4:39 PM, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 08.11.2007 22:22, Jesse Keating wrote:
On Thu, 08 Nov 2007 22:08:10 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Which still does not solve the problem that started this thread...
Correct. To solve the problem at the start of this thread, perhaps it would make sense to pre-populate the buildsystem with the next point release bits at the same time they're being staged for release, or close to it, so that EPEL can on the same day of a point release claim that they support that release. Just takes more cooperation between EPEL leaders and Red Hat.
And excludes all those contributers and users that don't have a RHEL license, as the resulting bits might lead to broken deps when one runs "yum update" on a CentOS machine right now (¹) with EPEL which depends on a lib that is shipped in the newly released RHEL update. Seems that's the case in the mail that started this thread. That would be totally unacceptable IMHO.
So... users that DO have a RHEL license will have to wait for CentOS devels to do their thing before they can get new packages? [...]
We don't have to; we can easily run a "cp -al 5 5.0" on the servers, put 5.1 on the builders and move on. Then users of CentOS or other clones as well as those RHEL-users that manually stick to 5.0 for a few days or week can use that repo. Some week later we can just delete the 5.0 directory.
CU knur
On Fri, 09 Nov 2007 07:18:45 +0100 fedora@leemhuis.info (Thorsten Leemhuis) wrote:
On 08.11.2007 23:27, Kyle Gonzales wrote:
On Nov 8, 2007 4:39 PM, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 08.11.2007 22:22, Jesse Keating wrote:
On Thu, 08 Nov 2007 22:08:10 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Which still does not solve the problem that started this thread...
Correct. To solve the problem at the start of this thread, perhaps it would make sense to pre-populate the buildsystem with the next point release bits at the same time they're being staged for release, or close to it, so that EPEL can on the same day of a point release claim that they support that release. Just takes more cooperation between EPEL leaders and Red Hat.
And excludes all those contributers and users that don't have a RHEL license, as the resulting bits might lead to broken deps when one runs "yum update" on a CentOS machine right now (¹) with EPEL which depends on a lib that is shipped in the newly released RHEL update. Seems that's the case in the mail that started this thread. That would be totally unacceptable IMHO.
So... users that DO have a RHEL license will have to wait for CentOS devels to do their thing before they can get new packages? [...]
We don't have to; we can easily run a "cp -al 5 5.0" on the servers, put 5.1 on the builders and move on. Then users of CentOS or other clones as well as those RHEL-users that manually stick to 5.0 for a few days or week can use that repo. Some week later we can just delete the 5.0 directory.
Yeah, this would leave 5.0 people potentially open to missing a security update, but thats not easily solved I don't think.
So, I would propose the following:
- Wait until centos 5.1 is released. - cp -al 5 5.0 in epel repos, update builders to 5.1, start using 5.1. - Wait a week - rm -rf 5.0; link 5 and 5.0 to 5.1.
CU knur
kevin
Jesse Keating wrote:
On Thu, 08 Nov 2007 22:08:10 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Which still does not solve the problem that started this thread...
Correct. To solve the problem at the start of this thread, perhaps it would make sense to pre-populate the buildsystem with the next point release bits at the same time they're being staged for release, or close to it, so that EPEL can on the same day of a point release claim that they support that release. Just takes more cooperation between EPEL leaders and Red Hat.
How does that help the millions of CentOS users out there?
Jesse Keating wrote:
On Thu, 08 Nov 2007 22:08:10 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
Which still does not solve the problem that started this thread...
Correct. To solve the problem at the start of this thread, perhaps it would make sense to pre-populate the buildsystem with the next point release bits at the same time they're being staged for release, or close to it, so that EPEL can on the same day of a point release claim that they support that release. Just takes more cooperation between EPEL leaders and Red Hat.
BTW ... if Red Hat would PROVIDE that SAME cooperation to CentOS, we would be more than happy to also RELEASE on the same day and solve this problem :D
epel-devel@lists.fedoraproject.org
-
Jesse Keating -
Johnny Hughes -
Kevin Fenzi -
Kyle Gonzales -
Richard W.M. Jones -
Stephen John Smoogen -
Thorsten Leemhuis