Hedayat Vatankhah schrieb:
Hi Tim,
Thank you a lot for your fast response and detailed answer. It is great.
That's what this SIG is meant to be good for :-)
On Mon, Jun 9, 2008 at 3:40 PM, Tim Niemueller <tim@xxxxxxxxxxxxx
<mailto:tim@xxxxxxxxxxxxx>> wrote:
...
Great! I've compiled the package and got some errors:
- Unpackaged file /usr/bin/rcssmonitor3D-lite, after adding this to the
%files section I could build it.
Oh, Thanks! Since I don't have freeglut-devel installed, this file
wasn't produced on my system. This file isn't useful now and I'll remove
it in the %install section.
OK.
- The devel packages triggers rpmlint warnings which have to be fixed:
# rpmlint rcssserver3d-devel-0.5.9-1.fc9.x86_64.rpm
rcssserver3d-devel.x86_64: W: no-documentation
...
/usr/lib64/rcssserver3d/libtinyxml.so libtinyxml.so.0.0.0
rcssserver3d-devel.x86_64: W: dangling-relative-symlink
...
rcssserver3d-devel.x86_64: E: only-non-binary-in-usr-lib
Would you please help me a little:
1. There are some documentation for developers, but since they're a
little big, I prefer to package them in a separate package. (They will
double the package size). However there are some HTML pages which I can
put here as documentation (I wanted to put them in the doc package). Is
it necessary to have some doc files?!
The main package should have README, AUTHORS, LICENSE files etc., the
verbose documentation is well-placed in the -doc subpackage. You can
ignore the no-documentation warning in that case for the other packages.
2. What should I do with dangling-relative-symlink warning? The symlinks
are valid, but the targets are in the main package. I don't know what
should I do to prevent these warnings :( What can I do?
The link should probably point to the full path, not just the file. Give
it a try, I'm not absolutely sure on this one.
3. I should go home and check it again, but I think there are only some
symlinks in /usr/lib. What's the problem? I don't know what else should
be in this directory as other files should be in the main package.
You mean for the very same problem?
- You should consider splitting the patch in one GCC4.3 and one
rpath patch
- You are a rcssserver3d committer, right? So why not commit the fixes
and build a package from SVN?
- The patches seem to contain changes besides fixing rpath and GCC 4.3,
are these changes necessary? Should be a separate patch then.
In fact, I first committed these change to rcssserver3d's CVS and then
created the patches using that. This is why all of the patches are in a
single file.
Yes, I personally prefer to create a package from CVS, but since one of
the review requirement was to compare the package's sources MD5 with
upstream release, I thought that I can't build a package from CVS. What
should I include in my review request if I build a package from the CVS
code?
Just a short explanation like "CVS contains fixes needed for proper
Fedora packaging". You need then a special release number like
0.5.10-0.1.cvs20080610. Note the release number of 0.1. This is required
to allow for proper upgrading when the final 0.5.10 is released.
- The explicit requires on the libraries shouldn't be necessary,
rpmbuild should be able to figure them out automatically
I was forced to add them for SUSE Build Service. Is there any need to
remove them?
It's a recommendation in the guidelines to *not* have these explicit
requires if not really necessary. You can just leave it out in the
Fedora block.
- What do you mean by comment 4, the "included some so files". What are
these .so files? If these libraries are part of rcssserver3d they should
be added! I don't really understand what you mean I think.
Sorry for this ambiguity. It is stated in Fedora packaging guidelines
that when a package includes versioned .so files, the .so symlinks must
go in the -devel package. But I can't do that since the server's binary
looks for these .so files. This is why only a few of .so files are in
the -devel package.
Does it explicitly dlopen these files? Auto-linking at runtime should
catch this otherwise. If it dlopens the files these could account as
"plugins" or so, and in that case I think it is fine to have these in
the main package.
I haven't done any runtime tests.
At least, they work on my system.
Good.
Tim
