>>>> This is quite interesting, I would recommend cross-posting to
>>>> foreman-users where you could get a bit more feedback from the
>>>> community, https://groups.google.com/forum/#!forum/foreman-users.
>>>>
>>>> If you are interested, it'd benefit both Foreman and you to make the
>>>> plugin official, as we provide an official rpm and deb repository, help
>>>> and infrastructure for packaging, etc… check out:
>>>> How to Create a Plugin - Foreman
>>>>
>>>> Major congrats!
>>>>
>>>
>>> Thank You for your kind words Daniel!
>>>
>>>
>>> There has been OpenSCAP 1.2.0 upstream release. Hence, we will be able
>>> to move forward and package whole plug-in set.
>>>
>>> I have managed to build all the rpms and the dependencies in my COPR repo:
>>>
>>> https://copr.fedoraproject.org/coprs/isimluk/OpenSCAP/
>>>
>>> It is not that easy as with other plug-ins, there are multiple packages
>>> needed. Here is a list:
>>>
>>> RHEL6 repository needs to include
>>>
>>> openscap-1.2.0+
>>
>> We wouldn't ship this, it would probably come from the distribution or a
>> third party repository.
>>
>
> Hello Dominic,
>
> OpenSCAP base package is in all distribution channels.
>
> The problems is that I have added a lot of new functionality in OpenSCAP
> only because of Foreman integration. Now the foreman_openscap requires
> the latest version: openscap-1.2.0.
>
> It will take some time before OpenSCAP 1.2.0 propagates to RHEL6 (It
> will be next week in Fedoras) In the mean time, I though it should be
> possible to include openscap-1.2.0 package in foreman-plugins.
Perhaps we can look at the actual detail when this is proposed, but my
general concerns would be that:
a) packages in our repos shouldn't replace distribution components
unless we have good reason and are happy it won't break things.
Sometimes we have replaced packages, and not always with great success,
sometimes destabilising a stable distro. (Once bitten, twice shy…)
b) maintenance burden, since if it's in our repos, we have to maintain
it. If it's being rebased in RHEL 6 and we can remove our package in
the near future, that's fine.
>>> RHEL7 repository needs to include
>>>
>>> openscap-1.2.0+
>>> ruby193-rubygem-rake-compiler
>>> ruby193-rubygem-ffi
>>
>> I've actually just targeted this spec file to be removed in an open PR,
>> but it can be moved to the plugin repo and built for EL7 too if you plan
>> to use it.
>>
>
> I see. That's pity.
No worries, I might remove it from my PR for now. We built a non-SCL
version of it before EPEL7 was available, and so we didn't have another
use of the spec file until now.
> I wonder why ruby193-rubygem-ffi is not in SCL.el7 anyway.
The ruby/ror SCLs are pretty minimalistic - they aim to provide the Ruby
runtime and Rails stacks with very little else. Unless it was an
indirect dependency of Rails, you probably won't find it in there.
That's the reason we carry so many additional packages… it would be
handy in theory if there was a general repo of miscellaneous rubygems,
but versioning would be a nightmare.
···
On 05/12/14 15:19, Simon Lukasik wrote:
> On 12/05/2014 12:47 PM, Dominic Cleal wrote:
>> On 05/12/14 11:36, Simon Lukasik wrote:
>>> On 11/07/2014 01:43 PM, Daniel Lobato wrote:
–
Dominic Cleal
Red Hat Engineering
