Hi! I've uploaded new SRPM and SPEC files. It would be nice if you or anybody else could have another look.
Thanks Hedayat
/*Tim Niemueller tim@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@niemueller.de mailto:tim@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:
- 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.
- 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.
- 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