11:03 p.m.
On 02/17/2012 10:19 PM, John Doyle wrote:
On 02/17/2012 09:44 AM, Itamar Heim wrote:
> On 02/17/2012 11:31 AM, Carlo de Wolf wrote:
>> I would like to come to a common packaging strategy for both RHEL&
>> Fedora for the whole AS 7 family and forward that as a recommendation to
>> Trevor.
>>
>> Specifically the issue I want to address is installing and possibly
>> running AS 7 and ovirt side-by-side.
>>
>> Subhendu and Julian put forward Jindrich's proposal of "Dynamic
Software
>> Collections".
>>
>> http://jnovy.fedorapeople.org/scl-utils/dsc.pp.pdf
>>
>> Would it make sense to use DSC as a base strategy?
>>
>> Who sees any obstacles and possible solutions?
>>
>> To kick off:
>> - interdepencies of DSCs are yet undefined, thus the whole multi-version
>> dependency management issue is only lifted to another level
>> - /opt is off-limits for Fedora. Can we use /usr/share instead?
> it is not about /opt, it is about the entire concept of having more than
> single version of each afaiu.
> spot?
>
> "Not approved for Fedora Packages
> Please note that official Fedora packages must not be configured as
> Software Collection packages. Fedora does not permit relocatable
> packages, packages using hierarchies that conflict or violate the FHS,
> or packages storing files in /opt. This documentation is NOT part of the
> Fedora Packaging Guidelines, and is only here should you wish to
> generate unofficial Software Collections against Fedora in a third-party
> repository."
> https://fedoraproject.org/wiki/SoftwareCollections
> _______________________________________________
> jboss-rpm mailing list
> jboss-rpm(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-rpm
I prefer software collections as our way to create Product RPMs, but I
don't see a way forward to a common strategy for Community on Fedora and
Products on RHEL. As Carlo points out, Fedora is blocking the way.
I don't see how we'd have bandwidth to do this differently for oVirt on
AS and rhev-m on eap. it's quite of an effort doing this once.
it is also a deployment choice. for the point of argument, rhev may
choose to use whichever version of jboss they want, it would still be
the jboss rpm's, as-is, right?
so why does it matter if they are part of software collections or not?
the way i see it, software collections only allow to have multiple
(mostly major) versions of same product (someone has to maintain all
these version streams).
I think more interesting is to solve allowing to easily create extend
the jbossas service for pre/post steps of other products, and allow to
launch multiple instances of it by creating a small wrapper service
script re-using it (i.e., even if we decide we want ovirt to run jboss
as ovirt-engine service, instead of jbossas service - I don't want to
re-write and maintain the jbossas service as the ovirt service.
I want the ovirt service to use the jbossas service implementation to do
so with minimal code (make the script a library, or just re-useable and
allow it to get a parameter of service name when i start it, etc.)