[Fedora Robotics] rcssserver3d Review Request

[Tim Niemueller]

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 at niemueller.de
> <mailto:tim at niemueller.de>> 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

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)