I've uploaded new SRPM and SPEC files. It would be nice if you or
anybody else could have another look.
/*Tim Niemueller <tim(a)niemueller.de>*/ wrote on 06/10/2008 08:31:25 PM:
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(a)niemueller.de
> <mailto:email@example.com>> 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.
> - 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
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
> - What do you mean by comment 4, the "included some so files". What
> 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.