[Bug 526916] Review Request: orc - The Oil Runtime Compiler

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=526916

--- Comment #24 from Nicolas Chauvet (kwizart) <kwizart at gmail.com> 2010-03-31 18:34:10 EDT ---
(In reply to comment #23)
...
> Done. Do you recommend this always, using -p ? If so this should be discussed
> somewhere (ml, bz).
This has been stated on the guidelines: 
http://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps
Once that said, it's true that it could have been handled with another macro,
the current %makeinstall macro been forbidden:
http://fedoraproject.org/wiki/Packaging:Guidelines#Why_the_.25makeinstall_macro_should_not_be_used


> > - Installed binary in devel: %{_bindir}/orcc
...
> So how can I handle this in the spec?
The current multilibs scheme picks the -devel package and search for packages
it depends on. If it bundles libraries, both versions of the dependent package
are copied into the 64bit repository. If it contains binaries, only one version
is copied into the 64bit repository.
So the best way is to split %{_bindir}/orcc into another package which is
required by the -devel.

> > SHOULD:
> > - doc subpackage can be set as noarch as it's rather big (450ko)
> 
> How can I establish this? %ifdef noarch?
You can use:
BuildArch: noarch
Within the %package -doc section. But this only work with newer Fedora.

> > - rpmlint on installed packages isn't clean:
> > # rpmlint orc
> > orc.x86_64: W: unused-direct-shlib-dependency /usr/lib64/liborc-0.4.so.0.0.0
> > /lib64/librt.so.1
> > orc.x86_64: W: unused-direct-shlib-dependency
> > /usr/lib64/liborc-float-0.4.so.0.0.0 /lib64/librt.so.1
> 
> I'm not that into autotools, but it seems as if this is hardcoded for alle orc
> libs: configure.ac:117.
Indeed, Once that said you don't need to fix overlinking, only underlinking
needs to be tracked as this often prevent preload to work with the underlinked
library.
It's only requested to warn upstream about that.

> > - It should be possible to avoid usage of generated header in the API:
> > orc/orc-stdint.h:#define _STDINT_HAVE_STDINT_H 1    
> 
> Sorry, I've got no clue what to do :)    
In an ideal world, a given API shouldn't be platform specific, so headers
generated at build time should be prevented (except for constant like for a
package to know which version it is). 
We don't use native -devel headers to cross compile to mingw32 or another cross
compilation target, so it doesn't matter that much.
Once that said, this orc/orc-stdint.h will be generated at build time, and the
32bit version will have a different time-stamp than the 64bit version. So you
need to do:
touch -r stamp-h1 %{buildroot}%{_includedir}/%{name}-0.4/orc/orc-stdint.h

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.