Dne 18.10.2017 v 16:18 James Hogarth napsal(a):
On 18 October 2017 at 15:15, James Hogarth
<james.hogarth(a)gmail.com> wrote:
> On 18 October 2017 at 14:35, Vít Ondruch <vondruch(a)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(a)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.
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?
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?
Vít