On 18 October 2017 at 15:52, Vít Ondruch vondruch@redhat.com wrote:
Dne 18.10.2017 v 16:18 James Hogarth napsal(a):
On 18 October 2017 at 15:15, James Hogarth james.hogarth@gmail.com wrote:
On 18 October 2017 at 14:35, Vít Ondruch vondruch@redhat.com wrote:
Dne 13.10.2017 v 21:49 James Hogarth napsal(a):
On 4 October 2017 at 15:16, James Hogarth james.hogarth@gmail.com wrote:
I have a Facter 3.9.0 package I'm happy with on initial testing. I'll be writing up a F28 self contained change shortly. I've tested puppet in F26 against this and it appears to behave correctly - would appreciate more eyes on it though.
The ruby- subpackage could be noarch IMO.
And it should depend on libfacter.so (probably instead of ruby dependency) ... but this code 'require "#{facter_dir}/lib64/libfacter.so"' is rather unfortunate, because it should not load the unversioned library, since this package belongs to -devel subpackage IMO. You have it in the main package for this reason I suppose, but that is wrong IMO:
https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages
Hmm is it valid to noarch a subpackage? How would it be able to pull in the correct arch'd dependency in that case?
With respect to where the .so is in %files and to that facter/rb requires line ... I tried to change it to the versioned .so and it fails to load it stating that it can't find the file (the fallback failure to load response) so check it exists etc etc ...
If you can make it work with it pointing to the versioned .so I'd be very happy ... I just fell back on what I could get working ;)
The relevant bit of policy surrounding that in the link you provided for this is:
"When in doubt as to whether a file belongs in the base package or in -devel, packagers should consider whether the file is necessary to be present for a user to use or execute the functionality in the base package properly, or if it is only necessary for development. If it is only necessary for development, it must go into a -devel package."
Seeing as I could not carry out a 'require facter' in a test ruby script with a versioned library there instead of the unversioned I figured it fell into the case where it is required to function properly ... and thus the unversioned .so according to the guidelines would fall within facter and not facter-devel
I'm happy to change the requires to require the library specifically rather than facter ... but I don't think that makes much difference beyond pure semantics as the library really needs to be with the facter package anyway as they are nto independently usable.
Err I meant to quote this section as it applies more specifically:
"The versioned shared library files (/usr/lib/libfoo.so.3.2.0 and /usr/lib/libfoo.so.3) are necessary for users to run programs linked against libfoo, so they belong in the base package. The other, unversioned, shared library file (/usr/lib/libfoo.so) is only used to actually link libfoo to code being compiled, and is not necessary to be installed on a users system. This means that it belongs in a -devel package. Please note that in most cases, only the fully versioned shared library file (/usr/lib/libfoo.so.3.2.0) is an actual file, all of the other files are symbolic links to it. When a shared library file is only provided in an unversioned format, the packager should ask upstream to consider providing a properly versioned library file. However, in such cases, if the shared library file is necessary for users to run programs linked against it, it must go into the base package. If upstream versions the shared library file at a future point, packagers must be careful to move to the versioned layout described above."
As I see it for the ruby bindings to work it needs to have the unversioned .so by my testing (again if you get it to work with it versioned happy to change this) so it belongs in the base package.
Hmm, trying this and thinking about it once more, it is obvious that ruby cannot load the versioned .so file using require.
Which would then mean according to guidelines it needs to be in the facter base package.
But still, I have couple more questions.
You probably wrote it somewhere and I just missed that, but what is actually purpose of the unversioned .so file? Is it used for development? I see there is -devel package, so the answer is YES I suppose. But anyway, wouldn't be better to place the .so link directly into the vendor_ruby directory (or create another link), so Ruby could load it without all the games with the path?
In current facter they have introduced golang bindings, though the complexity that adds I'm not planning on building them yet.
Similarly any independently developed application should be able to link against libfacter - ultimately it's not ruby specific.
As such I think it's best served in the system wide library area rather than make the decision to put it in ruby_vendor now and regret it later, when it would be more painful to change than at this early boundary point.
And there is one more thing to consider and I again have to reference the same line as previously: 'require "#{facter_dir}/lib64/libfacter.so"'. You see, there is "lib64" hardcoded. So what architectures are supported?
Actually upstream has it hardcoded to #{facter_dir}/lib/libfacter.so and I'm already having to patch it to %{_lib} on x64 to be sane with our preferences in Fedora.
It should all work on a i686 system - though I don't have one to test against right now (technically just installing facter.i686 instead of facter.x86_64 ought to be valid to test it though).
Referring to your other email ...
My key concern about making ruby-facter noarch is what would be required for the Requires ...
Since the ruby 'bindings' consists of just requiring the library directly wouldn't that actually make it arch specific and a noarch package wouldn't be aware if the user was on i686 or x64 to correctly pick the parent facter package...
Since facter.rb specifically calls on #{facter_dir}/%{_lib}/libfacter.so there would be no way in a noarch package to have dependencies all fall out correctly.