Spec URL: http://www.kobold.org/~wart/fedora/compat-guichan06.spec
SRPM URL: http://www.kobold.org/~wart/fedora/compat-guichan06-0.6.1-3.fc9.src.rpm
Compatibility library for guichan version 0.6.
The main guichan package will be upgraded to the latest 0.7.1 release at the same time that this package is imported. Currently only one package depends on libguichan-0.6.1 (ballz), and should not require a rebuild. It will, however, need to 'Requires: compat-guichan06-devel' and be patched slightly if/when it ever needs a rebuild.
Some questions / remarks.
I see this still installs its headers directly under /usr/include (atleast
guichan.hpp), wouldn't it be better to instead put them under
/usr/include/guichan-0.6 (both guichan.hpp and the guichan header dir).
Since this is also providing a -devel it should not be called compat-guichan06
but just guichan06.
Also is ballz the only user of guichan-0.6 ? If it is I could take a stab at
porting it, that would be better then carrying multiple versions for just one
Thanks for the quick check. Here is the updtae that puts the headers in the
I don't understand the reasoning for dropping compat- from the package name.
Why is 'compat-' not necessary for packages that provide a -devel subpackage?
As far as I know, ballz is the only dependency. I agree that porting ballz
would be ideal, but I have not had any time to look at porting, and I know that
you've been pretty busy lately, so this compat package seemed the quickest way
to work around it. It's probably still a good idea to keep this compat package,
however, in case there are any users who have compiled 3rd-party applications
against the library on their systems.
I've tried building ballz with guichan-0.7.1, and it turns out that all that is
needed is a simple rebuild.
I though that you had already tried that?
Anyways that means that a compat package for guichan-0.6 isn't (really) needed
and if you do one for binary compatibility reasons, you should remove all the
files which normally go to -devel after make install, and then indeed cal;l it
compat-foo, without a -devel subpackage.
Erm, ping? This no longer seems needed, so perhaps it should be closed, or ... ?
I think it should stick around, but for F-8 only. For F-9 we can upgrade to
guichan-0.7.1 and rebuild the affected packages. I'd also still like to upgrade
guichan for F-8 to help fix a lingering manaworld bug, but think that at least
the .so bits from guichan 0.6 should remain in case any users have locally built
packages that need them. The guichan 0.6.1 -devel bits can be dropped, however.
I'll update this package in the next day or so, and let you know in the same
timeframe when I'm about to push guichan-0.7.1 to rawhide.
After a bit of a delay, here is the package with the -devel bits removed:
I'm also ready to build guichan-0.7.1 for Rawhide.
Looks good, but since this now is a compat package (iow no devel, nothing in the
distro is building against, only made available for binary compatibility for old
apps if they need it), it should get the compat- back in its name.
Also I think we should only build this for F-8 and F-7, as we try not to keep
too much compat packages around in general.
I agree that this should only exist for F8 and F7. Nothing will require it in
F9, so there won't be any need to build it there.
New Package CVS Request
Package Name: compat-guichan06
Short Description: compatibility libraries for older guichan release
Branches: F-8 F-7
Imported and built for Rawhide. I've also built this for F-7 and F-8, but will
wait to do the push until ballz, manaworld, and guichan are all ready. guichan
is built for F-7 and F-8, but is waiting to be added to the build root so that
manaworld and ballz can be rebuilt.
Closing this, and will follow up with Hans via email to coordinate the other