Red Hat Bugzilla – Bug 210781
Review Request: libctl - Guile-based support for flexible control files
Last modified: 2007-11-30 17:11:45 EST
Spec URL: http://mitgcm.org/eh3/fedora_misc/libctl.spec
SRPM URL: http://mitgcm.org/eh3/fedora_misc/libctl-3.0.2-3.fc5.src.rpm
The libctl package is a Guile-based library that provides support for
flexible control files in scientific simulations.
Please note that the patch in the above SRPM has already been submitted
to the upstream folks. I hope to remove it and the resulting autotools
dependency from future versions.
The only thing that gives me any pause about this package is /usr/include/ctl.h,
which does seem a bit generic and prone to conflicts in the future. I don't
really know what to do about it, though. If it were moved into a subdirectory
of /usr/include or renamed, then Fedora would differ from every other
installation. And there's no convenient .pc file to use to relocate things.
Any thoughts on the matter?
* source files match upstream:
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
* build root is correct.
* license field matches the actual license.
* license is open source-compatible. License text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (development, x86_64).
* package installs properly
* debuginfo package looks complete.
* rpmlint is silent.
* final provides and requires are sane:
libctl = 3.0.2-3.fc6
libctl-devel = 3.0.2-3.fc6
libctl = 3.0.2-3.fc6
* %check is not present; no test suite upstream.
* shared libraries are present; ldconfig is called properly.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* scriptlets are OK (ldconfig)
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are in the -devel package.
* no pkgconfig files.
* no libtool .la droppings.
Hi Jason, many thanks for the rapid review!
So I can easily push the three header files into a /usr/include/ctl or
similarly named directory. And then use -I/usr/include/ctl for the
dependant packages (which will be submitted next). If I do that, will
you have any objections?
Alternatively, we could look through all the packages currently in Core
and Extras and convince ourselves that nothing else owns the admittedly
very generic-looking /usr/include/ctl.h file -- so that its OK for it to
I'm leaning towards the first one but will be OK with either solution
(or maybe even an alternative?). Please let me know what you prefer and
I'll probably just go ahead and implement it. :-)
Well, moving things to a directory is a reasonable solution. I guess the
question is whether /usr/include/ctl is really any better than
/usr/include/ctl.h and whether it's worth the trouble at all. I mean, every
downstream package will need work to accommodate. And normally I wouldn't bring
it up at all, except that there has been plenty of discussion about this issue
It's easy to check to see if anything else owns the file:
repoquery --whatprovides /usr/include/ctl.h
which shows that indeed nothing owns it. (I had checked this earlier.)
I guess that putting things in a directory under /usr/include is conceptually
quite clean and should be adopted by more packages. There shouldn't be any
objections as long as it's easy to fix the dependent packages.
My personnal opinion is that it is bad upstream practice to use
names that can clash, but I don't think this is an issue we should
solve at the packaging level except when a real conflict occurs.
I think that reporting the issue upstream should be a must item,
OK, here's an update that puts the three headers in a subdir:
and I'll deal with the "-I/usr/include/ctl" for the packages that
use it. Its easy enough to do!
OK, that looks fine to me.
Hi Jason, thank you for the review! It built successfully for FC-5 and
devel so I'm closing this bug. Thanks again!