https://bugzilla.redhat.com/show_bug.cgi?id=1485458 --- Comment #10 from Jonathan Dieter <jdieter@xxxxxxxxx> --- Thanks for addressing the issues I've listed. Responses inline and at the bottom: > (In reply to Jonathan Dieter from comment #8) > > (In reply to Martin Brandenburg from comment #0) > > If it's not built, you don't need to list the licenses. But I would wonder > > why you're not building these modules (obviously excepting the kernel > > module), and splitting them into subpackages so your users can easily get > > the parts of OrangeFS that they want. > > > Honestly for some of this, just getting it regularly built (and tested!) > will be an improvement to the status quo. It at least forces us to make > the decision whether to remove old crufty bits or keep them working. > > So I've enabled Karma, FUSE, and (stopped disabling) the usrint. That > leaves JNI and the webpack as far as I can see as optional things that > can be enabled. Looks good to me. > Then there's stuff like the caches where we have to consider stability > with and without. I will discuss this with other OrangeFS developers. > > I've enabled Infiniband as well. > > > > I am not sure how to handle this. I assume that the BSD/MIT style > > > licenses will not pose a problem, but I don't know where to document it. > > > > Normally like this: GPLv3 and BSD and ... Ok, a quick note on the licensing. The NTP license is actually a variant of MIT, and, at least according to https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx/thread/JM7YJILE4GIFRD3J636EAT2PBOEND7WP/, should be listed as such. And, according https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses, you can list LGPLv2.1 as LGPLv2. > > My recommendation would be to put pvfs2-genconfig in /usr/bin, as you > > already have, but possibly throw a simple config in > > /etc/orangefs/orangefs.conf. If the config could contain minimal (even if > > it doesn't work out of the box) configuration and a comment explaining the > > best way to properly generate it using pvfs2-genconfig, that would make it > > easy enough for even a non-documentation-reading sysadmin like myself to > > figure out what to do. > > > > Whatever you do, it looks like there are enough configuration files > > (certificates, etc as well as orangefs.conf) that it would be worth creating > > and owning /etc/orangefs/ and using that as your default configuration > > location. > > I've done this now. > > Most of the client applications look for /etc/pvfs2tab. Should I patch > it to look for /etc/orangefs/pvfs2tab? The server configuration is > given on the command line, but this is hardcoded (or settable by > environment variable). Thanks for this. If /etc/pvfs2tab is a well-known location, I sure wouldn't change it unless upstream is planning to make the change universal. > > > The utility programs distributed and others which can be linked against > > > our libraries will run against the server. It is also possible to use a > > > userspace client program along with the kernel module (distributed by > > > kernel.org and already present in Fedora). This would require running > > > the client program and mounting the filesystem through the kernel. I > > > suppose systemd scripts are needed, but I'm not sure what to distribute. > > > > If the client needs to be run with arguments to mount the filesystem, I'd > > probably not bother with a systemd service, but if it reads the > > configuration from /etc, a service might make sense. > > It doesn't need any arguments. The mount request comes in from the > kernel with all the information it needs. I've added a systemd unit for > it. > > I'm not sure how to arrange things so that systemd doesn't try to mount > the filesystem before the daemon is started. You could try putting After= in the mount unit file, which would order it after the server if and only if the server is also installed on the same machine. If there is no server on the local machine, then the client will start in parallel with everything else. > > > We have a component called the usrint which is a libc interposer. > > > Several of our utility programs require it now. It does not build on > > > all platforms. It is not required to run either the server or the > > > client. I have disabled it completely. > > > > If some of your utilities require it and it's important, I would probably > > check that it builds on all primary architectures. If it does, I'd enable > > it, and then use conditionals to disable building it on the arches it > > crashes on. Then open a bug for each arch it crashes on, (similar to what's > > described at > > https://fedoraproject.org/wiki/Packaging: > > Guidelines#Architecture_Build_Failures). It's possible someone who knows > > those arches may fix the bugs. If it doesn't build on all primary > > architectures (which I believe are currently ARM and x86_64), then I'd try > > to get it working at least for those, but it's not required by the > > guidelines. > > > > The one other thing I noticed is that you're packaging .a files in your > > -devel package. I'd remove them as part of your build process. > > I figure somebody may want to link statically, but I have no preference > either way, and this is easy to change. I've left it in for now, but > will remove if there's a Fedora policy or anyone has a strong opinion. Fedora has very specific guidelines if you're packaging static libraries (see: https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries, specifically the part about splitting static libraries into a separate subpackage), so I'd recommend just dropping the static libraries, unless you have a deep and overwhelming desire to deal with the extra red tape. ;) One major thing you need to do is remove the manual Provides in the orangefs client package. The reason the libraries aren't automatically being Provided: is that they're not executable, so you need to make sure they are installed with 0755 permissions. Once you do that, rpm will automatically add the Provides: for you. Hopefully this will sort out some of the rpmlint errors I'm seeing. I am a bit concerned by the shared-lib-calls-exit warning I'm getting. Do you intend for your library to actually exit the calling program as opposed to returning an error? -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
