https://bugzilla.redhat.com/show_bug.cgi?id=1485458
--- Comment #14 from Dave Love <dave.l...@manchester.ac.uk> ---
> > 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?
>
> Unfortunately, probably yes. I've done some quick grepping, and many of
> them look like places where an assert wouldn't be unreasonable.
For what it's worth, there are plenty of packages that won't worry
about that.
> > * Use ./prepare in %prep on straight exported source
>
> Should we? The release tarballs will not require it.
If you package from a release, no, it's not required. I don't know if
it's actually required otherwise, but it's normal ("best"?) practice.
> > * Use interface-related soname (see patch); the interface was
> > sufficiently stable over some previous versions I checked with
> > abipkgdiff to keep a major version.
>
> Thanks for this. I assume you are good with me merging your
> orangefs-soname.patch upstream?
Sure, if it's wanted.
> > * It needs an IB version (unless you can configure for both IB and TCP
> > now)
>
> It complains loudly that performance will suffer, but it's wrong or at
> least misleading. Performance will only suffer if you actually attempt
> to use both at the same time. Just having the code built and available
> for run-time configuration doesn't harm anything.
Oh, fine. I thought it was a real problem last time I asked. Can you
build with both and try to silence the complaint?
> > * Probably should have combinatorial builds over network and security
> > types too
>
> Do you use any of the security modes?
Probably not; I assumed others did.
> There's several network modes in src/io/bmi, but all we've focused on
> recently is bmi_tcp and bmi_ib. I'm not sure if the others build.
Tcp and IB are the only ones I'd worry about.
> I don't want to make something that is missing features people want to
> use.
>
> > * Remove the Provides: (but combinatorial builds should maybe provide
> > "orangefs")
> >
> > * Make -libs-<transport> packages for use with mpi-io etc.
>
> I have to admit I'm not entirely sure what you're talking about with
> either of these.
I think there was an explicit Provides of the libraries, which there
shouldn't be. With multiple packages for different security modes
(assuming you don't need them for different transports), you probably
want to be able to require something like "orangefs" to get one of
them.
Assuming the -<transport> bit isn't relevant now, I can't remember
what was there, but to build MPI-IO support, you need a -devel package
and a package just providing relevant libraries without pulling in
executables.
>
> > * Fix strange aarch64-specific build failure, but conditionalize it
> > for now -- ask about it on devel list?
> >
> > src/client/usrint/pvfs-path.c: In function 'PVFS_expand_path':
> > src/client/usrint/pvfs-path.c:266:25: error: 'SYS_readlink' undeclared
> > (first use in this function); did you mean 'SYS_readlinkat'?
> > n = syscall(SYS_readlink,
> > ^~~~~~~~~~~~
> > SYS_readlinkat
>
> They dropped obsolete syscalls in the kernel for the new architecture.
> That code is somewhat fragile (can't you tell from the fact it calls
> syscall instead of readlink?), so I'm not going to attempt to fix this,
> but I will forward the bug upstream.
You can at least conditionalize it so that you can build most of
orangefs on those platforms. I think I tested that.
> > * Expand description?
>
> Not a bad idea. May I take (and probably tweak) your description?
Sure, if its helpful.
> > * Include pacemaker stuff
>
> Again I have to admit I don't know what this is.
It's for high-availability support (not that I've used it). It's
trivial to put in, anyhow.
> > * pvfs2-{start,stop}-all should be %config as they need editing?
>
> They're also in /usr/sbin. Putting them somewhere as an example or
> extending them to take command line arguments may make more sense.
Yes, or somehow make them extensible.
> There's some argument here that we should not package Karma, because it
> may not work.
I had a note that it had been replaced by grafana support, which I
assume I got from the list, but it sounds as if that's wrong.
> I will test it. I've also been advised to add
> --disable-threaded, which is non-default but supposedly the thread does
> not help performance. I'm less excited about enabling a bunch of
> non-default (and thus poorly tested) options, though.
Right, if there's a good reason they're not defaulted other than build
requirements.
--
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@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
