Dne 18.10.2017 v 16:18 James Hogarth napsal(a):
> On 18 October 2017 at 15:15, James Hogarth <[email protected]> wrote:
>> On 18 October 2017 at 14:35, Vít Ondruch <[email protected]> wrote:
>>>
>>> Dne 13.10.2017 v 21:49 James Hogarth napsal(a):
>>>
>>>
>>>
>>> On 4 October 2017 at 15:16, James Hogarth <[email protected]> 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
_______________________________________________
ruby-sig mailing list -- [email protected]
To unsubscribe send an email to [email protected]
