Thanks for the reply.
On 4 Sep 2017 1:38 pm, "Vít Ondruch" vondruch@redhat.com wrote:
Hi James,
Not an Puppet/Facter expert, so just a few comments ...
Dne 4.9.2017 v 13:34 James Hogarth napsal(a):
Hi guys,
I'm getting the infrastructure in place ready for the mass bug filing and package updates for the removal of dependencies on net-tools in Fedora
https://pagure.io/fesco/issue/1711
One of the more tricky packages is facter.
Right now it's an old ruby package (2.4.3 when rubygems/github has it at 2.5.1 in the ruby variety).
The ruby version has the dependency on net-tools for ifconfig, but this was removed in the 3.0+ releases when they ported it to c++11
From the documentation it appears that ruby applications/libraries that use facter will still do so through the ruby binding just as they always have ... and looking at the puppet package it explicitly states that it works with facter greater than 2 and less than 4 ...
The puppetlabs puppet-agent already uses facter 3.8.0 in the current release.
The 2.5.1 tag in github is especially weird as it's not listed as a facter release here:
It seems that there was 2.4 release followed by 3.0 release and since that point, the 2.x branch was not refreshed. Probably some tooling issue on puppet side ...
It's rather odd. I plan on engaging with them directly to get an accurate answer. They don't ship the 2.X facter in their current puppet repos but there's clearly been releases since 2.4 on the 2.X line.
That even says 2.4 is now EOL, and has been since December last year.
Where?
On the page I linked it states:
Note: Facter versions prior to 3.0 will go end of life December 31, 2016. Please update if you haven’t already.
Also interestingly there's no reference to any facter 2.x after 2.4 in facter documentation... release notes after 2.4 go to 3.0
https://docs.puppet.com/facter/3.8/release_notes.html
I'll definitely contact upstream to get a clear answer on this and include it in the facter F28 change.
The tricky bits for the facter update are that it now has dependencies on https://github.com/puppetlabs/leatherman and https://github.com/puppetlabs/cpp-hocon
There's already a package review request for leatherman which I plan to take over, and I've got a shared library version of cpp-hocon ready for review (depends on leatherman) which facter3 is working with in my local testing.
The key bits I wanted to liaise with the ruby SIG for was the F28 change I'm putting together to get this update in place.
Although the application moves from ruby to c++ the ruby bindings will still be important and relevant to the SIG.
So is there some "preview" package of updated Facter?
I'm literally in the middle of getting it clean etc.
There's some stuff we'll need to get aligned in the spec for leatherman for instance.
Working on this stuff in my evenings, lunches and commutes so it's not fast going but I think F28 is reasonable as a goal for the change.
I'm in two minds whether to suggest we leave facter as it is for F25-27 or whether to at least update those to 2.5.1 which won't have the drastic 3.0 changes.
I expect an answer from upstream about the status of 2.x will help with that.
I've also not looked fully into the EPEL situation but from an initial cursory look of gemfiles I think the ruby versions there are out of their support matrix.
I'll also include those factors in the change when I write it.
I'll try and get initial test packages into COPR this week for feedback.
James
Dne 4.9.2017 v 14:58 James Hogarth napsal(a):
I'm in two minds whether to suggest we leave facter as it is for F25-27 or whether to at least update those to 2.5.1 which won't have the drastic 3.0 changes.
For me it is always clear. Keep the branched versions as they are unless you have really good arguments for upgrade.
I've also not looked fully into the EPEL situation but from an initial cursory look of gemfiles I think the ruby versions there are out of their support matrix.
Well, there is still just Ruby 1.8.7 in EPEL6 and these are rather old and incompatible (mainly due to encoding support and character handling). It should be better in EPEL7 with Ruby 2.0.0. Upstreams tends to drop official support for older Rubies (without any real reason except reducing the support matrix), but the code typically works (although you might need to relax some dependencies).
One thing to always consider is the dependency chain, including the build dependencies ...
Vít
On 5 Sep 2017 8:05 am, "Vít Ondruch" vondruch@redhat.com wrote:
Dne 4.9.2017 v 14:58 James Hogarth napsal(a):
I'm in two minds whether to suggest we leave facter as it is for F25-27 or whether to at least update those to 2.5.1 which won't have the drastic 3.0 changes.
For me it is always clear. Keep the branched versions as they are unless you have really good arguments for upgrade.
Usually I'd agree... but facter is way behind on bug fixes and hasn't seen an update in two years... a full three fedora releases ago.
A move to the most recent 2.X on the branches whilst 3.X is arranged in rawhide has decent justification... but I'll wait on what to do with that after a discussion with upstream.
I've also not looked fully into the EPEL situation but from an initial cursory look of gemfiles I think the ruby versions there are out of their support matrix.
Well, there is still just Ruby 1.8.7 in EPEL6 and these are rather old and incompatible (mainly due to encoding support and character handling). It should be better in EPEL7 with Ruby 2.0.0. Upstreams tends to drop official support for older Rubies (without any real reason except reducing the support matrix), but the code typically works (although you might need to relax some dependencies).
One thing to always consider is the dependency chain, including the build dependencies ...
Yeah this is another package that's just going to be left at an old version in EPEL6 I fear... I really wish we could link to Red Hat SCL packages for these situations... but oh well. Since my only direction/goal I this endeavour is the removal is the requirement of net-tools, and that's only Fedora, I'm not going to worry about it for now.
On 5 September 2017 at 08:15, James Hogarth james.hogarth@gmail.com wrote:
On 5 Sep 2017 8:05 am, "Vít Ondruch" vondruch@redhat.com wrote:
Dne 4.9.2017 v 14:58 James Hogarth napsal(a):
I'm in two minds whether to suggest we leave facter as it is for F25-27 or whether to at least update those to 2.5.1 which won't have the drastic 3.0 changes.
For me it is always clear. Keep the branched versions as they are unless you have really good arguments for upgrade.
Usually I'd agree... but facter is way behind on bug fixes and hasn't seen an update in two years... a full three fedora releases ago.
A move to the most recent 2.X on the branches whilst 3.X is arranged in rawhide has decent justification... but I'll wait on what to do with that after a discussion with upstream.
I've also not looked fully into the EPEL situation but from an initial cursory look of gemfiles I think the ruby versions there are out of their support matrix.
Well, there is still just Ruby 1.8.7 in EPEL6 and these are rather old and incompatible (mainly due to encoding support and character handling). It should be better in EPEL7 with Ruby 2.0.0. Upstreams tends to drop official support for older Rubies (without any real reason except reducing the support matrix), but the code typically works (although you might need to relax some dependencies).
One thing to always consider is the dependency chain, including the build dependencies ...
Yeah this is another package that's just going to be left at an old version in EPEL6 I fear... I really wish we could link to Red Hat SCL packages for these situations... but oh well. Since my only direction/goal I this endeavour is the removal is the requirement of net-tools, and that's only Fedora, I'm not going to worry about it for now.
Hi guys,
Here's a status update for this change.
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.
I'm having issues with cmake3 in EPEL7 not picking up the cmake files from the leatherman package preventing me from building there - so that will stay on 2.5.X for now, similar to F26 and F27 will be updated shortly staying within the 2.5.X series for compatibilty concerns.
If you'd like to test the facter 3.9.0 packages this COPR can be used:
https://copr.fedorainfracloud.org/coprs/jhogarth/facter3/
We'll need to coordinate on the F28 package so puppet can depend on ruby-facter instead of facter ... I'll do a repoquery to see if I can locate any similar packages using the ruby bindings as well.
Cheers,
James
On 4 October 2017 at 15:16, James Hogarth james.hogarth@gmail.com wrote:
On 5 September 2017 at 08:15, James Hogarth james.hogarth@gmail.com wrote:
On 5 Sep 2017 8:05 am, "Vít Ondruch" vondruch@redhat.com wrote:
Dne 4.9.2017 v 14:58 James Hogarth napsal(a):
I'm in two minds whether to suggest we leave facter as it is for F25-27 or whether to at least update those to 2.5.1 which won't have the drastic 3.0 changes.
For me it is always clear. Keep the branched versions as they are unless you have really good arguments for upgrade.
Usually I'd agree... but facter is way behind on bug fixes and hasn't seen an update in two years... a full three fedora releases ago.
A move to the most recent 2.X on the branches whilst 3.X is arranged in rawhide has decent justification... but I'll wait on what to do with that after a discussion with upstream.
I've also not looked fully into the EPEL situation but from an initial cursory look of gemfiles I think the ruby versions there are out of their support matrix.
Well, there is still just Ruby 1.8.7 in EPEL6 and these are rather old and incompatible (mainly due to encoding support and character handling). It should be better in EPEL7 with Ruby 2.0.0. Upstreams tends to drop official support for older Rubies (without any real reason except reducing the support matrix), but the code typically works (although you might need to relax some dependencies).
One thing to always consider is the dependency chain, including the build dependencies ...
Yeah this is another package that's just going to be left at an old version in EPEL6 I fear... I really wish we could link to Red Hat SCL packages for these situations... but oh well. Since my only direction/goal I this endeavour is the removal is the requirement of net-tools, and that's only Fedora, I'm not going to worry about it for now.
Hi guys,
Here's a status update for this change.
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.
I'm having issues with cmake3 in EPEL7 not picking up the cmake files from the leatherman package preventing me from building there - so that will stay on 2.5.X for now, similar to F26 and F27 will be updated shortly staying within the 2.5.X series for compatibilty concerns.
If you'd like to test the facter 3.9.0 packages this COPR can be used:
https://copr.fedorainfracloud.org/coprs/jhogarth/facter3/
We'll need to coordinate on the F28 package so puppet can depend on ruby-facter instead of facter ... I'll do a repoquery to see if I can locate any similar packages using the ruby bindings as well.
Cheers,
James
To keep the ruby sig and relevant package owners/reviewers in the loop ... the change for Facter3 in F28 has been approved.
https://pagure.io/fesco/issue/1767#comment-472520
I'll get the boost-nowide review request in over the weekend, which will unblock leatherman and cpp-hocon can then be submitted as well.
The initial spec files that need a final tuning for submission, and which were used for the COPR, can be found here:
https://jhogarth.fedorapeople.org/facter3/
We've got plenty of time according to the schedule but it'd be nice to get this resolved in rawhide sooner rather than later :)
https://fedoraproject.org/wiki/Releases/28/Schedule
James
Dne 13.10.2017 v 21:49 James Hogarth napsal(a):
On 4 October 2017 at 15:16, James Hogarth <james.hogarth@gmail.com mailto: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
Vít
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.
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.
Dne 18.10.2017 v 16:15 James Hogarth napsal(a):
Hmm is it valid to noarch a subpackage? How would it be able to pull in the correct arch'd dependency in that case?
I was not supported by old RPM, but that is long time ago. Noarch subpackages are used for example in Ruby packages and they works just fine.
What does not work is arch subpackage of noarch package though (but that is not the case).
V.
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.
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
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.
On 13 October 2017 at 20:49, James Hogarth james.hogarth@gmail.com wrote:
On 4 October 2017 at 15:16, James Hogarth james.hogarth@gmail.com wrote:
On 5 September 2017 at 08:15, James Hogarth james.hogarth@gmail.com wrote:
On 5 Sep 2017 8:05 am, "Vít Ondruch" vondruch@redhat.com wrote:
Dne 4.9.2017 v 14:58 James Hogarth napsal(a):
I'm in two minds whether to suggest we leave facter as it is for F25-27 or whether to at least update those to 2.5.1 which won't have the drastic 3.0 changes.
For me it is always clear. Keep the branched versions as they are unless you have really good arguments for upgrade.
Usually I'd agree... but facter is way behind on bug fixes and hasn't seen an update in two years... a full three fedora releases ago.
A move to the most recent 2.X on the branches whilst 3.X is arranged in rawhide has decent justification... but I'll wait on what to do with that after a discussion with upstream.
I've also not looked fully into the EPEL situation but from an initial cursory look of gemfiles I think the ruby versions there are out of their support matrix.
Well, there is still just Ruby 1.8.7 in EPEL6 and these are rather old and incompatible (mainly due to encoding support and character handling). It should be better in EPEL7 with Ruby 2.0.0. Upstreams tends to drop official support for older Rubies (without any real reason except reducing the support matrix), but the code typically works (although you might need to relax some dependencies).
One thing to always consider is the dependency chain, including the build dependencies ...
Yeah this is another package that's just going to be left at an old version in EPEL6 I fear... I really wish we could link to Red Hat SCL packages for these situations... but oh well. Since my only direction/goal I this endeavour is the removal is the requirement of net-tools, and that's only Fedora, I'm not going to worry about it for now.
Hi guys,
Here's a status update for this change.
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.
I'm having issues with cmake3 in EPEL7 not picking up the cmake files from the leatherman package preventing me from building there - so that will stay on 2.5.X for now, similar to F26 and F27 will be updated shortly staying within the 2.5.X series for compatibilty concerns.
If you'd like to test the facter 3.9.0 packages this COPR can be used:
https://copr.fedorainfracloud.org/coprs/jhogarth/facter3/
We'll need to coordinate on the F28 package so puppet can depend on ruby-facter instead of facter ... I'll do a repoquery to see if I can locate any similar packages using the ruby bindings as well.
Cheers,
James
To keep the ruby sig and relevant package owners/reviewers in the loop ... the change for Facter3 in F28 has been approved.
https://pagure.io/fesco/issue/1767#comment-472520
I'll get the boost-nowide review request in over the weekend, which will unblock leatherman and cpp-hocon can then be submitted as well.
The initial spec files that need a final tuning for submission, and which were used for the COPR, can be found here:
https://jhogarth.fedorapeople.org/facter3/
We've got plenty of time according to the schedule but it'd be nice to get this resolved in rawhide sooner rather than later :)
https://fedoraproject.org/wiki/Releases/28/Schedule
James
Hi guys,
Further update for this update ;)
General stuff -------------------
The work of Denis Arnaud has got boost157 packaged as an option in EPEL (as of a few minutes or so when I approve the package review).
The boost-nowide dependency has it's own review and has been tested in both F27 and F26 as well as with the boost157 package to build leatherman, and packages further down the tree.
https://bugzilla.redhat.com/show_bug.cgi?id=1502584
The leatherman spec in my fedorapeople space was used to build the version in the COPR with cpp-hocon using that leatherman package to build and facter3 using that to build/run.
https://jhogarth.fedorapeople.org/facter3/
https://copr.fedorainfracloud.org/coprs/jhogarth/facter3/
I've not submitted the cpp-hocon review yet as it's dependent on the boost-nowide one anyway.
Obviously as you can see in the COPR the new facter 3 builds fine in EPEL7 and Fedora with the boost157 package and these two dependencies in place.
This is all fine for Fedora and puts us in a great place to get this all into place in plenty of time before F28 even branches.
Note that although I've built facter3 in the COPR for EPEL7 (using that boost157 package) and facter itself works fine ... the older puppet in EPEL (3.6.2 in EPEL7) is not compatible with the more recent facter.
I'm not sure exactly yet where the specific breakage happens and haven't had time to dig through all the old puppet release notes to see where the facter compatibility changes.
Does the Ruby-SIG have any plans to get puppet updated in EPEL7? If so we can get the new facter there too ... if not we'll need to hold back and I'm not even sure if the 2.5.X releases of facter would be compatible.
Specific questions to people --------------------------------------
Haikel, have you had time to review the changes to the leatherman spec and patches proposed to bring your review up to date? Do you have time to finish through on that review once the boost-nowide module is approved?
Gaël, are you happy remaining POC or would you prefer I get any bug reports after we push facter3 out?
Vit, are you okay to adjust the puppet dependency in fedora to ruby-facter once we get the dependencies built or would you prefer I coordinate that change with the facter update as a Proven Packager?
Thanks for all you help and time guys,
James
Dne 25.10.2017 v 16:22 James Hogarth napsal(a):
Vit, are you okay to adjust the puppet dependency in fedora to ruby-facter once we get the dependencies built or would you prefer I coordinate that change with the facter update as a Proven Packager?
Sorry, but my knowledge of Puppet is close to zero, except the fact that it is written in Ruby, so I don't think I am the right person to answer your question ;) But I might try to help if my help is needed ...
V.
On 25 October 2017 at 15:38, Vít Ondruch vondruch@redhat.com wrote:
Dne 25.10.2017 v 16:22 James Hogarth napsal(a):
Vit, are you okay to adjust the puppet dependency in fedora to ruby-facter once we get the dependencies built or would you prefer I coordinate that change with the facter update as a Proven Packager?
Sorry, but my knowledge of Puppet is close to zero, except the fact that it is written in Ruby, so I don't think I am the right person to answer your question ;) But I might try to help if my help is needed ...
V.
Haha no worries ... you're just the only mail I've had from anyone in the ruby SIG and it's the SIG that is maintaining puppet to my knowledge so you ended up on my named list ;)
Trying very hard not to break your puppet packages there ;)
ruby-sig@lists.fedoraproject.org
-
James Hogarth -
Vít Ondruch