I wanted to install the latest Subversion, version 1.5.1, on CentOS 5. I knew it wouldn't be in the CentOS repos (although I checked anyway) so I went looking in Fedora Rawhide and pulled down the SRPM I found there. I attempted to build it and it failed due to a missing "perl-devel" package. Some investigation indicates that somewhere in Fedora's history the headers and development utilities in Perl got broken out into a separate subpackage. It looks like this happened at 5.8.8-15.
This is mostly a heads-up to others that might run into this, but I'm wondering what the best way to deal with it is. Should I comment out the BuildReq, or create a virtual package that provides perl-devel and depends on the existing perl package?
Kenneth Porter wrote:
I wanted to install the latest Subversion, version 1.5.1, on CentOS 5. I knew it wouldn't be in the CentOS repos (although I checked anyway) so I went looking in Fedora Rawhide and pulled down the SRPM I found there. I attempted to build it and it failed due to a missing "perl-devel" package. Some investigation indicates that somewhere in Fedora's history the headers and development utilities in Perl got broken out into a separate subpackage. It looks like this happened at 5.8.8-15.
This is mostly a heads-up to others that might run into this, but I'm wondering what the best way to deal with it is. Should I comment out the BuildReq, or create a virtual package that provides perl-devel and depends on the existing perl package?
change perl-devel to perl
On Wed, 30 Jul 2008, Kenneth Porter wrote:
I wanted to install the latest Subversion, version 1.5.1, on CentOS 5.
...
This is mostly a heads-up to others that might run into this, but I'm wondering what the best way to deal with it is. Should I comment out the BuildReq, or create a virtual package that provides perl-devel and depends on the existing perl package?
I would just rpmbuild with --nodeps.
On 07/31/2008 12:02 AM, Charlie Brady wrote:
On Wed, 30 Jul 2008, Kenneth Porter wrote:
I wanted to install the latest Subversion, version 1.5.1, on CentOS 5.
...
This is mostly a heads-up to others that might run into this, but I'm wondering what the best way to deal with it is. Should I comment out the BuildReq, or create a virtual package that provides perl-devel and depends on the existing perl package?
I would just rpmbuild with --nodeps.
Wrong approach. Apply Johnny's advice. Or be polite and modify the spec to distinguish between building on fedora >=7 or on Centos (RHEL). Something along the following line should do:
%if 0%{?fedora} > 6 BuildRequires perl-devel %else BuildRequires perl %endif
--On Thursday, July 31, 2008 12:29 AM +0300 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Wrong approach. Apply Johnny's advice. Or be polite and modify the spec to distinguish between building on fedora >=7 or on Centos (RHEL). Something along the following line should do:
%if 0%{?fedora} > 6 BuildRequires perl-devel %else BuildRequires perl %endif
That almost works. The spec parser didn't like the leading white space on BuildRequires, and it's missing the colon. The following seems to work:
%if 0%{?fedora} > 6 BuildRequires: perl-devel >= 2:5.8.0 %else BuildRequires: perl >= 2:5.8.0 %endif
On Wed, 30 Jul 2008, Kenneth Porter wrote:
--On Thursday, July 31, 2008 12:29 AM +0300 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Wrong approach. Apply Johnny's advice. Or be polite and modify the spec to distinguish between building on fedora >=7 or on Centos (RHEL). Something along the following line should do:
%if 0%{?fedora} > 6 BuildRequires perl-devel %else BuildRequires perl %endif
That almost works. The spec parser didn't like the leading white space on BuildRequires, and it's missing the colon. The following seems to work:
%if 0%{?fedora} > 6 BuildRequires: perl-devel >= 2:5.8.0 %else BuildRequires: perl >= 2:5.8.0 %endif
Since the subversion people never report releases on freshmeat, I often find out that a new release is made by people informing me, or by accident (like now).
I have updated my subversion package to 1.5.1. But only on EL5, for EL4 and older there is a problem with libneon (and SSL functionality). You should be able to pull it from RPMforge tomorrow during the day.
Kind regards,
--On Thursday, July 31, 2008 2:48 AM +0200 Dag Wieers dag@centos.org wrote:
Since the subversion people never report releases on freshmeat, I often find out that a new release is made by people informing me, or by accident (like now).
Why not subscribe to subversion-announce?
http://subversion.tigris.org/servlets/ProjectMailingListList
On Thu, 31 Jul 2008, Kenneth Porter wrote:
--On Thursday, July 31, 2008 2:48 AM +0200 Dag Wieers dag@centos.org wrote:
Since the subversion people never report releases on freshmeat, I often find out that a new release is made by people informing me, or by accident (like now).
Why not subscribe to subversion-announce?
http://subversion.tigris.org/servlets/ProjectMailingListList
Because it would be hell to track 4000 other projects like that. Freshmeat is a good centralised system to track new releases of Open Source software. It would be nice of they used it as well.
Besides, anyone can report a new release so it does not necessarily need to be done by the subversion release team (although that would be ideal).
Kind regards,
--On Thursday, July 31, 2008 3:42 PM +0200 Dag Wieers dag@centos.org wrote:
Because it would be hell to track 4000 other projects like that. Freshmeat is a good centralised system to track new releases of Open Source software. It would be nice of they used it as well.
Besides, anyone can report a new release so it does not necessarily need to be done by the subversion release team (although that would be ideal).
Interesting. I'd always thought Freshmeat was a hosting site, not an index. I'll post to subversion-devel to let them know they need to post an update.
On Thursday, July 31, 2008 12:29 AM +0300 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Wrong approach. Apply Johnny's advice. Or be polite and modify the spec to distinguish between building on fedora >=7 or on Centos (RHEL). Something along the following line should do:
%if 0%{?fedora} > 6 BuildRequires perl-devel %else BuildRequires perl %endif
I supplied this as a proposed patch to Rawhide and was told that:
Raw Hide spec files are not designed to be built on any distro other than Raw Hide; you need to fork the spec and keep distro-specific hacks in the fork.
Kenneth Porter wrote:
On Thursday, July 31, 2008 12:29 AM +0300 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Wrong approach. Apply Johnny's advice. Or be polite and modify the spec to distinguish between building on fedora >=7 or on Centos (RHEL). Something along the following line should do:
%if 0%{?fedora} > 6 BuildRequires perl-devel %else BuildRequires perl %endif
I supplied this as a proposed patch to Rawhide and was told that:
Raw Hide spec files are not designed to be built on any distro other than Raw Hide; you need to fork the spec and keep distro-specific hacks in the fork.
yea, we know ... hence the centos project is supporting rpmrepo and not epel
On Mon, Aug 4, 2008 at 3:04 PM, Johnny Hughes johnny@centos.org wrote:
Kenneth Porter wrote:
On Thursday, July 31, 2008 12:29 AM +0300 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Wrong approach. Apply Johnny's advice. Or be polite and modify the spec to distinguish between building on fedora >=7 or on Centos (RHEL). Something along the following line should do:
%if 0%{?fedora} > 6 BuildRequires perl-devel %else BuildRequires perl %endif
I supplied this as a proposed patch to Rawhide and was told that:
Raw Hide spec files are not designed to be built on any distro other than Raw Hide; you need to fork the spec and keep distro-specific hacks in the fork.
yea, we know ... hence the centos project is supporting rpmrepo and not epel
I don't see how this has anything to do with EPEL. Subversion and perl are core EL product not EPEL.
Stephen John Smoogen wrote:
On Mon, Aug 4, 2008 at 3:04 PM, Johnny Hughes johnny@centos.org wrote:
Kenneth Porter wrote:
On Thursday, July 31, 2008 12:29 AM +0300 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Wrong approach. Apply Johnny's advice. Or be polite and modify the spec to distinguish between building on fedora >=7 or on Centos (RHEL). Something along the following line should do:
%if 0%{?fedora} > 6 BuildRequires perl-devel %else BuildRequires perl %endif
I supplied this as a proposed patch to Rawhide and was told that:
Raw Hide spec files are not designed to be built on any distro other than Raw Hide; you need to fork the spec and keep distro-specific hacks in the fork.
yea, we know ... hence the centos project is supporting rpmrepo and not epel
I don't see how this has anything to do with EPEL. Subversion and perl are core EL product not EPEL.
The specific issue does not ... the concept does (we do things our way only). But that is not really relevant and I do not want to start a flame thread with 1000 posts, so I take back my criticism.
On Mon, Aug 4, 2008 at 3:28 PM, Johnny Hughes johnny@centos.org wrote:
Stephen John Smoogen wrote:
On Mon, Aug 4, 2008 at 3:04 PM, Johnny Hughes johnny@centos.org wrote:
Kenneth Porter wrote:
On Thursday, July 31, 2008 12:29 AM +0300 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Wrong approach. Apply Johnny's advice. Or be polite and modify the spec to distinguish between building on fedora >=7 or on Centos (RHEL). Something along the following line should do:
%if 0%{?fedora} > 6 BuildRequires perl-devel %else BuildRequires perl %endif
I supplied this as a proposed patch to Rawhide and was told that:
Raw Hide spec files are not designed to be built on any distro other than Raw Hide; you need to fork the spec and keep distro-specific hacks in the fork.
yea, we know ... hence the centos project is supporting rpmrepo and not epel
I don't see how this has anything to do with EPEL. Subversion and perl are core EL product not EPEL.
The specific issue does not ... the concept does (we do things our way only). But that is not really relevant and I do not want to start a flame thread with 1000 posts, so I take back my criticism.
And I will take back my counter-criticism as I don't want a flame war..
Johnny Hughes wrote:
Stephen John Smoogen wrote:
On Mon, Aug 4, 2008 at 3:04 PM, Johnny Hughes johnny@centos.org wrote:
Kenneth Porter wrote:
On Thursday, July 31, 2008 12:29 AM +0300 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Wrong approach. Apply Johnny's advice. Or be polite and modify the spec to distinguish between building on fedora >=7 or on Centos (RHEL). Something along the following line should do:
%if 0%{?fedora} > 6 BuildRequires perl-devel %else BuildRequires perl %endif
I supplied this as a proposed patch to Rawhide and was told that:
Raw Hide spec files are not designed to be built on any distro other than Raw Hide; you need to fork the spec and keep distro-specific hacks in the fork.
yea, we know ... hence the centos project is supporting rpmrepo and not epel
I don't see how this has anything to do with EPEL. Subversion and perl are core EL product not EPEL.
The specific issue does not ... the concept does (we do things our way only). But that is not really relevant and I do not want to start a flame thread with 1000 posts, so I take back my criticism.
I've reopened the bug and asked Joe if I could maintain the little tiny patch in the rawhide spec if he wouldn't.
I hope that clarifies the attitude EPEL and Fedora people have.
Kind regards,
Jeroen van Meeuwen -kanarip
Johnny Hughes wrote:
Kenneth Porter wrote:
On Thursday, July 31, 2008 12:29 AM +0300 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Wrong approach. Apply Johnny's advice. Or be polite and modify the spec to distinguish between building on fedora >=7 or on Centos (RHEL). Something along the following line should do:
%if 0%{?fedora} > 6 BuildRequires perl-devel %else BuildRequires perl %endif
I supplied this as a proposed patch to Rawhide and was told that:
Raw Hide spec files are not designed to be built on any distro other than Raw Hide; you need to fork the spec and keep distro-specific hacks in the fork.
yea, we know ... hence the centos project is supporting rpmrepo and not epel
Do they really consider backwards-compatibility to be a distro-specific hack? Sounds suicidal to me.
Les Mikesell wrote:
Do they really consider backwards-compatibility to be a distro-specific hack?
3 lines in a spec file? It's maintainable, sustainable and not a very user unfriendly thing to do.
Sounds suicidal to me.
Funny. Suicide is for mortals.
:/
Kind regards,
Jeroen van Meeuwen -kanarip
On Aug 4, 2008, at 7:12 PM, Jeroen van Meeuwen wrote:
Les Mikesell wrote:
Do they really consider backwards-compatibility to be a distro- specific hack?
3 lines in a spec file? It's maintainable, sustainable and not a very user unfriendly thing to do.
Sounds suicidal to me.
Funny. Suicide is for mortals.
Please stop the histrionics, chicken little. The sky is not falling ...
Joe Orton is merely remarking that a patch in the "rawhide" branch does not help other branches like "f9", "f8", etc etc, ...
Do the math: Maintaining a patch in a "rawhide" spec file that never appears in other, commonly used branches of a VCS is pointless.
73 de Jeff
--On Monday, August 04, 2008 9:30 PM -0400 Jeff Johnson n3npq@mac.com wrote:
Joe Orton is merely remarking that a patch in the "rawhide" branch does not help other branches like "f9", "f8", etc etc, ...
Do the math: Maintaining a patch in a "rawhide" spec file that never appears in other, commonly used branches of a VCS is pointless.
The raw Subversion tarball has autoconfig stuff to make it adapt to a wide variety of systems. Why is it so hard to get RPM to do the same thing, esp. on two distros that are so similar?
On Aug 5, 2008, at 10:06 AM, Kenneth Porter wrote:
--On Monday, August 04, 2008 9:30 PM -0400 Jeff Johnson n3npq@mac.com wrote: The raw Subversion tarball has autoconfig stuff to make it adapt to a wide variety of systems. Why is it so hard to get RPM to do the same thing, esp. on two distros that are so similar?
Its not hard, see the trivial 3 line patch to a spec file to handle the adaptation to a wider variety of systems.
But that misses the context of Joe Orton's reply in the bugzilla RFE entirely.
The rawhide *.spec is targeted at rawhide, not everywhere, because of the branch structure in use by Fedora. That has nothing whatsoever to do with whether Fedora is "suicidal" or "RPM sux!", there's a perfectly obvious engineering explanation for why the RFE was declined.
73 de Jeff
On Tuesday, August 05, 2008 10:46 AM -0400 Jeff Johnson n3npq@mac.com wrote:
The rawhide *.spec is targeted at rawhide, not everywhere, because of the branch structure in use by Fedora. That has nothing whatsoever to do with whether Fedora is "suicidal" or "RPM sux!", there's a perfectly obvious engineering explanation for why the RFE was declined.
If the Fedora branch structure precludes compatibility with other distros, should CentOS users avoid use of Rawhide packages when seeking newer upstream packages, and instead migrate to another repository? Doesn't this discourage greater testing of Rawhide? Only those who use a "pure" Rawhide distro will have any incentive to use its packages.
On Aug 5, 2008, at 12:57 PM, Kenneth Porter wrote:
On Tuesday, August 05, 2008 10:46 AM -0400 Jeff Johnson n3npq@mac.com wrote:
The rawhide *.spec is targeted at rawhide, not everywhere, because of the branch structure in use by Fedora. That has nothing whatsoever to do with whether Fedora is "suicidal" or "RPM sux!", there's a perfectly obvious engineering explanation for why the RFE was declined.
If the Fedora branch structure precludes compatibility with other distros, should CentOS users avoid use of Rawhide packages when seeking newer upstream packages, and instead migrate to another repository? Doesn't this discourage greater testing of Rawhide? Only those who use a "pure" Rawhide distro will have any incentive to use its packages.
All valid and important points.
Old Russian saying: Don't blame a dog for its master.
Barking at Joe Orton for refusing an RFE and somehow trolling/spinning that into "Fedora is sucidal!" and "RPM sux!" is a waste of time and energy.
And I agree that "RPM sux!" fwiw ...
73 de Jeff
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Tuesday, August 05, 2008 12:59 PM -0400 Jeff Johnson n3npq@mac.com wrote:
Old Russian saying: Don't blame a dog for its master.
Who in this case is the master? Where can we find the policy declaration, and the people responsible for it? Are they aware of the side effects?
Barking at Joe Orton for refusing an RFE and somehow trolling/spinning that into "Fedora is sucidal!" and "RPM sux!" is a waste of time and energy.
"Suicide" sounds like hyperbole but I think the intent was just to say that the "engineering" is discouraging participation.
And I agree that "RPM sux!" fwiw ...
LOL
On Aug 5, 2008, at 1:15 PM, Kenneth Porter wrote:
On Tuesday, August 05, 2008 12:59 PM -0400 Jeff Johnson n3npq@mac.com wrote:
Old Russian saying: Don't blame a dog for its master.
Who in this case is the master? Where can we find the policy declaration, and the people responsible for it? Are they aware of the side effects?
Time for you to find out methinks ...
73 de Jeff
On Tue, Aug 5, 2008 at 12:12 PM, Jeff Johnson n3npq@mac.com wrote:
On Aug 5, 2008, at 1:15 PM, Kenneth Porter wrote:
Who in this case is the master? Where can we find the policy declaration, and the people responsible for it? Are they aware of the side effects?
When wearing my Fedora Tester hat, I often check the Guidelines : https://fedoraproject.org/wiki/Packaging/Guidelines Joe, and his high-and-mighty-rawhideness, also seems to directly conflict with %{dist} tag use : https://fedoraproject.org/wiki/Packaging/DistTag
On Tue, Aug 5, 2008 at 9:46 AM, Jeff Johnson n3npq@mac.com wrote:
The rawhide *.spec is targeted at rawhide, not everywhere, because of the branch structure in use by Fedora. That has nothing whatsoever to do with whether Fedora is "suicidal" or "RPM sux!", there's a perfectly obvious engineering explanation for why the RFE was declined.
Then the Fedora build structure is severely flawed. In other words, we "dogs" have dysfunctional "masters". Come on team - we should practice like we play, right? :-)
jerry
On Tuesday, August 05, 2008 12:43 PM -0500 Jerry Amundson jamundso@gmail.com wrote:
Some interesting text at the bottom of that page, justifying exclusion of RPMForge's disttags:
RPMForge precedes the distribution value with a numeric value, designed to assist in upgrades between versions of Red Hat Linux, Red Hat Enterprise Linux, and Fedora. I really don't think that an upgrade path between RHEL and Fedora is viable, or something that we should attempt to promote. If Fedora used the same dist tags, we'd be implying that there was support for upgrading between drastically different distributions. It also adds an extra layer of complexity to the Release field, confusing users and new packagers.
Is not RHEL (and, by extension, CentOS) a cherry-picked snapshot of Fedora? Will the next RHEL not be some slice of Fedora? If RHEL comes from Fedora, then at some point in time the current RHEL will need to be upgradable to some extraction of Fedora.
On Tue, 5 Aug 2008, Kenneth Porter wrote:
On Tuesday, August 05, 2008 12:43 PM -0500 Jerry Amundson jamundso@gmail.com wrote:
Some interesting text at the bottom of that page, justifying exclusion of RPMForge's disttags:
Is not RHEL (and, by extension, CentOS) a cherry-picked snapshot of Fedora? Will the next RHEL not be some slice of Fedora? If RHEL comes from Fedora, then at some point in time the current RHEL will need to be upgradable to some extraction of Fedora.
Please let foreign project practices not be argued here. ... again ... for what seems like the 20th time.
Fedora has its views, and RPMForge its. Neither is CentOS. CentOS just replicates an upstream's free bits. ONCE RELEASED. No sense in reading tea leaves here.
-- Russ herrold
R P Herrold wrote:
Some interesting text at the bottom of that page, justifying exclusion of RPMForge's disttags:
Is not RHEL (and, by extension, CentOS) a cherry-picked snapshot of Fedora? Will the next RHEL not be some slice of Fedora? If RHEL comes from Fedora, then at some point in time the current RHEL will need to be upgradable to some extraction of Fedora.
Please let foreign project practices not be argued here. ... again ... for what seems like the 20th time.
Fedora has its views, and RPMForge its. Neither is CentOS. CentOS just replicates an upstream's free bits. ONCE RELEASED. No sense in reading tea leaves here.
It doesn't matter who does it or where - making something that is not inherently backwards compatible is bound to cause pain.
On Tue, 5 Aug 2008, Ralph Angenendt wrote:
Les Mikesell wrote:
It doesn't matter who does it or where - making something that is not inherently backwards compatible is bound to cause pain.
As does making something which has to be backwards compatible all the time.
Exactly, both comments conjured a smile on my face :)
On Aug 5, 2008, at 6:06 PM, Dag Wieers wrote:
On Tue, 5 Aug 2008, Ralph Angenendt wrote:
Les Mikesell wrote:
It doesn't matter who does it or where - making something that is not inherently backwards compatible is bound to cause pain.
As does making something which has to be backwards compatible all the time.
Exactly, both comments conjured a smile on my face :)
While I'm happy to see a smile on yer face, and backward compatibility is incredibly important (you are one of the few who understands that importance),
*BUT*
I'm forced to point out that the engineering changes that led to the creation of perl-devel packaging are quite sound. The perl package always was a messy mixture of modules and other "stuff", pretending otherwise is foolish.
One needs to balance fixes against compatibility on a case by case basis. No one rule, or one policy, can be generally applied.
73 de Jeff -- who really doesn't wish to be an apologetic advocate of Fedora "suicide"
On Tue, 5 Aug 2008, Jeff Johnson wrote:
On Aug 5, 2008, at 6:06 PM, Dag Wieers wrote:
On Tue, 5 Aug 2008, Ralph Angenendt wrote:
Les Mikesell wrote:
It doesn't matter who does it or where - making something that is not inherently backwards compatible is bound to cause pain.
As does making something which has to be backwards compatible all the time.
Exactly, both comments conjured a smile on my face :)
While I'm happy to see a smile on yer face, and backward compatibility is incredibly important (you are one of the few who understands that importance),
*BUT*
I'm forced to point out that the engineering changes that led to the creation of perl-devel packaging are quite sound. The perl package always was a messy mixture of modules and other "stuff", pretending otherwise is foolish.
One needs to balance fixes against compatibility on a case by case basis. No one rule, or one policy, can be generally applied.
You are misreading the smile !
But I feel no urge to explain, maybe it will come up next year in a pub in Brussels ;-)
On Aug 5, 2008, at 8:47 PM, Dag Wieers wrote:
On Tue, 5 Aug 2008, Jeff Johnson wrote:
You are misreading the smile !
But I feel no urge to explain, maybe it will come up next year in a pub in Brussels ;-)
No need to explain, -ENOCONTEXT is a valid errno ;-)
See ya next year!
73 de Jeff
On Tue, Aug 5, 2008 at 7:47 PM, Dag Wieers dag@centos.org wrote:
But I feel no urge to explain, maybe it will come up next year in a pub in Brussels ;-)
Thanks for the invite! (assuming that applied to everyone :-)
Though, now that I look, T-DOSE is coming up, and PSV has a match the same weekend - I might need some time off dayjob in October...
jerry
On Tue, 5 Aug 2008, Jerry Amundson wrote:
On Tue, Aug 5, 2008 at 7:47 PM, Dag Wieers dag@centos.org wrote:
But I feel no urge to explain, maybe it will come up next year in a pub in Brussels ;-)
Thanks for the invite! (assuming that applied to everyone :-)
Definitely :-)
Hi,
On Tue, Aug 05, 2008 at 11:10:35AM -0700, Kenneth Porter wrote:
On Tuesday, August 05, 2008 12:43 PM -0500 Jerry Amundson jamundso@gmail.com wrote:
Some interesting text at the bottom of that page, justifying exclusion of RPMForge's disttags:
RPMForge precedes the distribution value with a numeric value, designed to assist in upgrades between versions of Red Hat Linux, Red Hat Enterprise Linux, and Fedora. I really don't think that an upgrade path between RHEL and Fedora is viable, or something that we should attempt to promote. If Fedora used the same dist tags, we'd be implying that there was support for upgrading between drastically different distributions. It also adds an extra layer of complexity to the Release field, confusing users and new packagers.
Is not RHEL (and, by extension, CentOS) a cherry-picked snapshot of Fedora? Will the next RHEL not be some slice of Fedora? If RHEL comes from Fedora, then at some point in time the current RHEL will need to be upgradable to some extraction of Fedora.
The above text refers to making CentOS5 say be between FC6 and F7. The disttags like 0.fc6, 1.el5, 2.f7 (just examples, the real ones look a bit different) ensure that FC6 < EL5 < F7 in rpm semantics.
What the text says is that RHEL does not want to be considered as a linear succession to Fedora and a upcoming Fedora release a succession to this, but rather as a fork from FC6 with its own evolution that didn't necessarily flow back to F7.
Also RHEL/CentOS/SL/etc are a subset of Fedora, so a larger FC6 install will not fully upgrade to CentOS5.
In general while it is quite possible to upgrade (or sidegrade?) from CentOS to Fedora and the other way around, the general approach should be a fresh install when doing that.
Other than that I think Fedora and RHEL clearly accept their intertwined relationship. Neither could exist w/o the other.
Kenneth Porter wrote:
On Thursday, July 31, 2008 12:29 AM +0300 Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Wrong approach. Apply Johnny's advice. Or be polite and modify the spec to distinguish between building on fedora >=7 or on Centos (RHEL). Something along the following line should do:
%if 0%{?fedora} > 6 BuildRequires perl-devel %else BuildRequires perl %endif
I supplied this as a proposed patch to Rawhide and was told that:
Raw Hide spec files are not designed to be built on any distro other than Raw Hide; you need to fork the spec and keep distro-specific hacks in the fork.
Awesome attitude from Mister Joe. I'll take it. Let's get it over with.
-Jeroen
Hi,
On Wed, Jul 30, 2008 at 01:23:05PM -0700, Kenneth Porter wrote:
I wanted to install the latest Subversion, version 1.5.1, on CentOS 5. [...] I attempted to build it and it failed due to a missing "perl-devel" package. Some investigation indicates that somewhere in Fedora's history the headers and development utilities in Perl got broken out into a separate subpackage. [...]
This is mostly a heads-up to others that might run into this, but I'm wondering what the best way to deal with it is. Should I comment out the BuildReq, or create a virtual package that provides perl-devel and depends on the existing perl package?
I'd go for the latter. That is how I also deal with python-devel/python(abi)/python-abi for older CentOSes or xfree86 -> xorg changes (see the compat package at ATrpms). It is the cleanest and less maintenance needing solution, as you will not need to touch the subversion specfile, at least not in this part.
In general I try to package up things for the latest bits of CentOS/RHEL/etc (which is indeed RawHide, even if it is years before it shows up as a CentOS release) and try (as much as possible) to keep the same specfile for elder environments with virtual provides, stub packages etc.
But a perl-devel stub would be nice for CentOS plus/extras and certainly for rpmrepo - which should also ship a newer subversion package in its replacement tagged repos.
BTW did you check Dag's repo for a CentOS packages subversion? I just did, it doesn't yet carry 1.5.x, but I'm sure if you ask Dag it will soon do (although I think currently Dag enjoys some well deserved off-the-net-time).
On Tue, Aug 05, 2008 at 03:32:21AM +0300, Axel Thimm wrote:
BTW did you check Dag's repo for a CentOS packages subversion? I just did, it doesn't yet carry 1.5.x, but I'm sure if you ask Dag it will soon do (although I think currently Dag enjoys some well deserved off-the-net-time).
OK, made an you-should-have-read-the-whole-thread-before-you-answer- fool out of me. I see that Dag already catered for this. Remove that paragrpah from the protocol, please. :)
On Tuesday, August 05, 2008 3:32 AM +0300 Axel Thimm Axel.Thimm@ATrpms.net wrote:
I'd go for the latter. That is how I also deal with python-devel/python(abi)/python-abi for older CentOSes or xfree86 -> xorg changes (see the compat package at ATrpms). It is the cleanest and less maintenance needing solution, as you will not need to touch the subversion specfile, at least not in this part.
I'm inclined to agree. Fundamentally the problem isn't in the Subversion package, but with the split in the Perl package. The solution should not be to pollute dependent packages with conditional hacks but to create a one-time stand-in for the future package split in the RHEL/CentOS branch that will occur when the Fedora Perl packaging change gets pushed down into RHEL.
-
Axel Thimm -
Charlie Brady -
Dag Wieers -
Jeff Johnson -
Jeroen van Meeuwen -
Jerry Amundson -
Johnny Hughes -
Kenneth Porter -
Les Mikesell -
Manuel Wolfshant -
R P Herrold -
Ralph Angenendt -
Stephen John Smoogen