Red Hat Bugzilla – Bug 247376
Please rebuild osgal/osgcal for new OpenThreads (rawhide)
Last modified: 2007-11-30 17:12:09 EST
openalpp has been in the rawhide broken deps reports for a couple of days now:
openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1
Please rebuild openalpp or I can give it a spin if you're ok with that.
I guess Ralf updated OSG to 2.0 last week. I'll fire off rebuilds of openalpp,
osgal and osgcal. Hopefully there won't be any build issues (knock on wood). :)
Build fails. Says it is missing openthreads, where I clearly include
OpenThreads-devel in the root.log. Perhaps OpenThreads-devel is not including a
pkgconfig file in devel or something?
I guess I'll have to figure out what is going on when I have some more free time...
oops forgot to paste the build log:
The problem indeed is that OpenThreads 2 doesn't have a pkgconfig file, once
thats worked-around it compiles fine. (not tested!).
I'll attach a spec file diff + patch which I've sued to work around the missing
pkgconfig file. Notice this is not pretty (I hate autoXXXX) but it works.
Adding Ralf (the OpenThreads maintainer) to the CC, Ralf maybe its a food idea
to add a pkgconfig file to OpenThreads in the package, the removal of this file
may break compiling other apps too, and openthreads otherwise _seems_ API
Created attachment 158732 [details]
specfile patch / hack to get openalpp to compile with new openthreads
Created attachment 158733 [details]
configure patch / hack to get openalpp to compile with new openthreads
Do you need this right away? If so, I can just add the openthreads.pc file as a
patch and set the pkgconfig file path to . (dot). This should work as suggested
by Loic. Otherwise if Ralf plans on adding pkgconfig files back in the OSG
packages I'd rather wait for that.
I've no need for this atm, I just noticed it in the broken deps report. Waiting
for what Ralf wants todo seems like the best plan to me too.
Well, I am not sure what to do about this.
With OSG-1, the pkgconfig files initially had been part a Debian patches, but
later (IIRC, with 1.2) had been adopted by upstream (I.e. upstream had made
pkgconfig part of their package/API).
With OSG-2, upstream has dropped pkgconfig.
I.e. though technically re-adding the pkgconfig files to Fedora's OSG package is
not much of a problem, any package which is using OSG and is relying on
OSG-pkgconfig support files, doesn't comply to OSG-2's programming environment.
It's a pity, but that's one side-effect of upstream decisions.
Also, let me note that I am still undecided on how to proceed with OSG.
I am leaning to revert Fedora's OSG back to OSG-1 and to add a new OSG-2 package.
(In reply to comment #9)
> Well, I am not sure what to do about this.
Well, the packages I maintain (openalpp, osgcal, and osgal) which rely on OSG
libraries are not updated very often. I think it would be nice if you could
provide the pkgconfig files through the Fedora 8 cycle in order to give the
upstream maintainers of these projects some time to fix their config scripts and
what not for OSG 2.0. I do not see this as being harmful, because the upstream
developers of the projects I package use the upstream version of OSG, not the
Fedora packaged version.
Is there anyone other than me who packages stuff for Fedora that relies on OSG libs?
Upstream has informed me that there are numerous issues with osg2. He has
suggested to go ahead and make an osg1-compat rpm.
(In reply to comment #11)
> Upstream has informed me that there are numerous issues with osg2.
Which upstream? I tried to check and found what seems to be a dead and
discontinued project (http://alpp.sourceforge.net)
http://sourceforge.net/projects/osgal however claims to have released an osg2.0
poker3d depends on openalpp & osgal in their pre-osg2 version. The API of
openalpp changed and the api of osg2 version also changed. poker3d would need to
be ported to these new versions. osgcal also depends on osg1.2 and needs to be
ported to osg2. There may be a number of packages for which there does not exist
an official fedora package suffering from the same problem. It makes sense, I
think, to keep a version of osg1.2 active even after the new major osg2 is being
published. Just like you still have db3, db4, etc.
Loic Dachary firstname.lastname@example.org
Ralf, we have an osgcal ready which is osg2 compatible, but we need a pkgconfig
file to be packaged with osg2, can you please add one? Debian added one which
can be seen here:
(In reply to comment #14)
> Ralf, we have an osgcal ready which is osg2 compatible, but we need a pkgconfig
> file to be packaged with osg2, can you please add one?
Are you current sources in CVS? I'd have to re-check details.
Several weeks ago, I once did and had been able to build openal or openalpp
> Debian added one which
> can be seen here:
Well, Debian is introducing an API which doesn't exist upstream :/
The .pc files existed in 1.2 and were removed in 2.0 when Robert Osfield moved
to CMake. I should talk Robert into re-introducing the .pc in the distribution
once again. However, before 2.0 these files were constantly out-dated because
Robert is a windows user and does not need these files. In the end it was the
responsibility of the packager to fix these files. I'm not too hot for another
20 mails session about the virtues of pkgconfig, specialy if it turns out to be
outdated most of the time. Instead, I think it makes sense to consider that
these files are packaging tools in the same sense as the dependencies. I hope
you can see my point of view. If you don't I'll have to do some work on my own
software (osgal + osgcal) to accomodate for the lack of .pc file. I'd rather
have you do some work and me doing nothing. But I'd understand if you prefer me
doing some work and you doing nothing to improve the packaging of openscenegraph ;-)
(In reply to comment #16)
> The .pc files existed in 1.2 and were removed in 2.0 when Robert Osfield moved
> to CMake.
Right, upstream abandoned it.
> I should talk Robert into re-introducing the .pc in the distribution
> once again.
Feel free to do so. When upstream re-adds them, they will re-appear in Fedora.
> However, before 2.0 these files were constantly out-dated
Then you probably have not been using Fedora. The OSG in Fedora is heavily
patched to get things close to being functional.
> Robert is a windows user and does not need these files. In the end it was the
> responsibility of the packager to fix these files.
This is the wrong view: It was inevitable for the packager to do so, because
upstream shipped broken files.
> Instead, I think it makes sense to consider that
> these files are packaging tools in the same sense as the dependencies.
The point is: Upstream defines a package's API. pkgconfig is part of this.
If upstream abandons something, upstream has drawn a decision - A packages users
have to follow, whether they want or not.
> I hope
> you can see my point of view. If you don't I'll have to do some work on my own
> software (osgal + osgcal) to accomodate for the lack of .pc file.
Pardon, but then your work is based on ilegimate assumptions and you will have
to find a different solution.
> I'd rather have you do some work and me doing nothing.
> But I'd understand if you prefer me
> doing some work and you doing nothing to improve the packaging of
> openscenegraph ;-)
Apparently you are not able to comprehend: OSG2 has changed the API. Now it's
its client-applications's (your) job to follow or these client applications are
Whether upstream's decisions are good or not, is irrelvant, as well as the fact
that Debian has re-added the *.pc's.
BTW: In packages with properly integrated pkgconfig support, it's possible to
pass the required *_CFLAGS and *_LIBS from the configure-line.
IIRC, pkgconfig support in osgal and osgcal are broken wrt. this.
(In reply to comment #17)
> (In reply to comment #16)
> > However, before 2.0 these files were constantly out-dated
> Then you probably have not been using Fedora. The OSG in Fedora is heavily
> patched to get things close to being functional.
Whatâˆ You heavily patched the pkgconfig files with OSG1 essentially *changing
the API* according to your definition of what a pkgconfig file is, and you wont
do it for OSG2?
I'm throwing my hands up in the air here. What the hell Ralf. Just add a
pkgconfig file for heavens sake. A pkgconfig file does not change the API, you
do not harm anything by adding one.
Am I just stupid, or are you Ralf making a big deal out of nothing. I'm
probably just stupid.
Let me put this another way Ralf. Instead of you waiting for upstream to supply
a pkgconfig file, why dont you just add one yourself, and send it for upstream
to include. This is the best and proper way to proceed.
# repoquery --archlist=src --repoid=updates-source --repoid=fedora-source
--repoid=dribble-source --repoid=livna-source --whatrequires OpenSceneGraph-devel
As far as I can tell, I have the *only* packages that use OSG-devel. Now if I
say I need a pkgconfig file, why wont you comply? It only affects me, myself
and I. We are making efforts to get upstream to re-include the pkgconfig files,
your help would be appreciated.
*** PLEASE PLEASE PLEASE JUST RE-ADD THE PKGCONFIG FILE I LINKED TO ***
(In reply to comment #20)
> # repoquery --archlist=src --repoid=updates-source --repoid=fedora-source
> --repoid=dribble-source --repoid=livna-source --whatrequires OpenSceneGraph-devel
> As far as I can tell, I have the *only* packages that use OSG-devel.
> Now if I say I need a pkgconfig file, why wont you comply?
Because the fact these package depend on OSG shipping a pkgconfig file are BUGS
inside of these packages.
They rely upon what had been in OSG1, but had been abandoned by upstream in
OSG2, and Debian seems to have re-added as an isolated Debian-proprietary hack.
> It only affects me, myself and I. We are making efforts to get upstream to
> re-include the pkgconfig files, your help would be appreciated.
Grant me access to CVS and I'll build openalpp w/o OSG's pkgconfig files.
Fixing this is a matter of minutes (I have patches pending).
Whether this would be reasonable is a different matter. As pointed out before,
this version of openalpp is dead, discontinued and unmaintained. IMO, it should
be removed from Fedora.
Whether this will help you wrt. osgal and osgcal is a yet another question.
osgal's configure definitely is too buggy to allow building w/o pkgconfig files.
Fixing this is possible, but I don't know it this will help you at all or if
this won't reveal further OSG1/OSG2 compatibility issues.
> *** PLEASE PLEASE PLEASE JUST RE-ADD THE PKGCONFIG FILE I LINKED TO ***
I will add them once upstream does - Until then, I recommend you to fix these
Adding a pkgconfig file is not a hack. openalpp is not the issue. openalpp is
going away with the next release of osgal (they are being combined).
(In reply to comment #22)
> Adding a pkgconfig file is not a hack.
Are you deaf or what?
How many times do I have to repeat?
Upstream has decided not to ship the pkgconfig files (and apparently doesn't
consider to do so). => Any package relying on these pkgconfig files to be
present is BROKEN, BUGGED, MIS-DESIGNED - In short: crap.
> openalpp is not the issue.
OK, then the question must be allowed why you haven't been able to fix the
package? I had offered you to help, but you once again rejected it.
> openalpp is
> going away with the next release of osgal (they are being combined).
Then update. I had asked you for the your sources, because, given the poor shape
the current osgal is I am expecting the worst. You once more preferred not to
answer ... your liberty.
I am waiting on the next release of osgal. Once it is ready, I will update
osgal and obsolete openalpp. But that probably wont be possible if you continue
to be stubborn about the pkgconfig file.
OSG upstream is windows centric, they probably don't even know what a pkgconfig
file is. Did you actually bother e-mailing upstream and asking about it? You
need to be more proactive. We need the pkgconfig file, it makes life easier.
If you let upstream know that packages that depend on osg-devel on linux need a
pkgconfig file and you provide him with one, then upstream will add it.
It is not a hack to add a pkgconfig file because upstream doesn't know why they
are needed. The proper thing to do is to educate the OSG folks on why pkgconfig
files are good.
I'm starting to think you have some personal vendetta against pkgconfig files.
(In reply to comment #24)
> OSG upstream is windows centric, they probably don't even know
> what a pkgconfig file is.
Rubbish - They even had it in OSG1.
> Did you actually bother e-mailing upstream and asking about it?
Why should I? THEY define what THEY want. YOU simply don't want to comprehend,
that they dictate how their package is supposed to be used, not some trashy
> need to be more proactive. We need the pkgconfig file,
RUBBISH - YOU need to fix YOUR package to match what upstream expects.
> I'm starting to think you have some personal vendetta against pkgconfig files.
Absolutely no. I simply refuse to cripple and hack packages because somebody is
not able to fix the bugs the packages he is trying to maintain.
I don't see any use in continuing to waste my time on this.
Ralf, if another package requires that pkgconfig file, I don't see what's wrong
with adding it, especially given that the file has been provided already! There
are other packages with Fedora-added .pc files too. Please try thinking in the
overall interest of Fedora instead of defending principles all the time.
Additionally, compatibility with Debian is also an important reason to add
the .pc file. Even if you don't like what Debian is doing, being gratuitously
incompatible with them helps no one.
Thanks for the helpful comments, but Ralph has removed himself from the CC.
http://dfn.dl.sourceforge.net/sourceforge/osgal/osgal-0.6.1.tar.gz has just been
published with autotools fixes. Good to know .pc files will be provided.
osgal 0.6.1 with osg2 support built for f8
osgcal 0.1.46 with osg2 support built for f8
openalpp is now obsoleted by osgal 0.6.1 and the release engineering team has
been notified that the openalpp package is now a dead.package.
These packages are not marked for Test 3 because the needed updates for the
OpenSceneGraph package did not make it in Test 3.