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 -- Tim Niemueller <tim@xxxxxxxxxxxxx> www.niemueller.de ================================================================= Imagination is more important than knowledge. (Albert Einstein) _______________________________________________ Fedora-robotics-list mailing list Fedora-robotics-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-robotics-list
