Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   EPEL Development (http://www.linux-archive.org/epel-development/)
-   -   'policy' for multiple versions of same software in EPEL (http://www.linux-archive.org/epel-development/711273-policy-multiple-versions-same-software-epel.html)

Greg Swift 10-10-2012 06:13 PM

'policy' for multiple versions of same software in EPEL
 
So... I've paid attention to the conversations around this because i
was a long time zabbix user, so it affected me in that I had to build
my own 'latest' packages usually or download from the maintainer's
personal repository. If I remember correctly it has also been
discussed around lots of web apps like bugzilla as well.

But now its something that is potentially going to affect me more as I
jumped on as a co-maintainer of collectd in the recent pre-orphaning
package spree and started trying to get rspec-puppet packaged [1] due
to requirements @dayjob.

So in the sidebar discussion about collectd the following was in the thread:

>> One thing to work on is to create new EPEL-only collectd5 package, see
>> https://bugzilla.redhat.com/show_bug.cgi?id=743894#c4
>> In c6 there's collectd5.spec contributed by eolamey - remaining issues
>> could be worked around by adding explicit Conflicts: collectd so that
>> file and module paths don't need to change.
> This is something to avoid if at all possible, IMHO.
> http://fedoraproject.org/wiki/Packaging:Conflicts

But a few weeks ago in the Zabbix discussion on list [2] I saw:

>> One of the options was to change the package name and host both
>> releases in EPEL. I'm not sure how often this actually happens, or
>> what the path to get there would be.
> That's the approach we took. zabbix20 conflicts with zabbix. ..snip..

I've read through the Packaging:Conflicts wiki. I just don't feel
like it adequately addresses the EPEL 'newer' version scenario. Maybe
that is just cause I'm missing something (in which case can someone
clarify for me, and maybe we can make it clearer in the wiki?) or
because it just isn't defined. I'll concede that some examples listed
of packages that perform each of the various 'solutions' described
would be awesome and might resolve some of the lack of clarity.

So the two scenarios I'm looking at:

1: collectd [3] - to make version 5 available in epel5/6 will have to
submit collectd5 package. Most of the work is done, but right now the
created package 'conflicts' due to duplicate library files and the
perl-Collectd module needing to be renamed. I can usually package up
software pretty readily, and I don't know how to do what is needed to
do this without more guidance (more admin than dev). Because of what
the software is, I'd imagine most people are running either version 4
or version 5. Some people might be running both environments from the
server side (separate collectors), but aren't likely to have a
monitored (client) system active in both.

2: rubygem-rspec (no associated bugzilla entry that I am aware of yet)
- to make rspec-puppet available in epel 5/6 version 2 of rspec needs
to be made available. I assume this means that the same general
concept of rspec2 package needing to be initiated begins. With this
one there appears to be way more impact as there are at least 3
packages that build on top of rspec currently. [4] Because this is
more of a library set of packages, and most of those packages perform
different functionality for rspec that may not always be for the same
end use cases it makes conflicts a harder possibility. So i'd imagine
either a) have to do a parallel installable rspec2 release of all of
them that conflicts so that the 'gems' themselves don't need to be
adjusted or b) adjust the entire rubygem so that it behaves as rspec2
and make the other gems use rspec2 rather than rspec.


thoughts?

thanks

greg/xaeth



[1] https://bugzilla.redhat.com/show_bug.cgi?id=787350
[2] http://www.redhat.com/archives/epel-devel-list/2012-September/msg00037.html
[3] https://bugzilla.redhat.com/show_bug.cgi?id=743894
[4] although upon further review.. it appears that none are branched
into epel and all are current with rspec2, which negates a lot of the
conflicts and actually would open them up to epel....

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Kevin Fenzi 10-12-2012 09:53 PM

'policy' for multiple versions of same software in EPEL
 
On Wed, 10 Oct 2012 13:13:41 -0500
Greg Swift <gregswift@gmail.com> wrote:

> So... I've paid attention to the conversations around this because i
> was a long time zabbix user, so it affected me in that I had to build
> my own 'latest' packages usually or download from the maintainer's
> personal repository. If I remember correctly it has also been
> discussed around lots of web apps like bugzilla as well.

Yeah.

There's a lot of apps out there that have a different release cycle
that RHEL has, so we have to try and adjust to that. Keeping in mind
that most people who are using RHEL don't like things changing very
much.

...snip...

> So the two scenarios I'm looking at:
>
> 1: collectd [3] - to make version 5 available in epel5/6 will have to
> submit collectd5 package. Most of the work is done, but right now the
> created package 'conflicts' due to duplicate library files and the
> perl-Collectd module needing to be renamed. I can usually package up
> software pretty readily, and I don't know how to do what is needed to
> do this without more guidance (more admin than dev). Because of what
> the software is, I'd imagine most people are running either version 4
> or version 5. Some people might be running both environments from the
> server side (separate collectors), but aren't likely to have a
> monitored (client) system active in both.

Right. I think this may be something we want to ask the Fedora
Packaging folks (who live on the packaging list) about.

The main problem with conflicts is that it's something that is detected
by yum at the 'test' stage. It means you have chosen, downloaded a
bunch of stuff and then yum tells you, "WOAH, these confict, fix it and
try again". This is not very friendly. If you do this in the installer
it's even worse.

In this case I guess your reasoning makes sense to me, people are
unlikely to want to run both at the same time on clients. However, on
servers they might... what parts of them would conflict?

> 2: rubygem-rspec (no associated bugzilla entry that I am aware of yet)
> - to make rspec-puppet available in epel 5/6 version 2 of rspec needs
> to be made available. I assume this means that the same general
> concept of rspec2 package needing to be initiated begins. With this
> one there appears to be way more impact as there are at least 3
> packages that build on top of rspec currently. [4] Because this is
> more of a library set of packages, and most of those packages perform
> different functionality for rspec that may not always be for the same
> end use cases it makes conflicts a harder possibility. So i'd imagine
> either a) have to do a parallel installable rspec2 release of all of
> them that conflicts so that the 'gems' themselves don't need to be
> adjusted or b) adjust the entire rubygem so that it behaves as rspec2
> and make the other gems use rspec2 rather than rspec.

Well, this is a reasoning for rspec2 to be completely parallel
installable. Can't those things that wish continue to use rspec1?
Or would that lead to mixing them both since they are in the same
stack?

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

Greg Swift 10-13-2012 03:35 AM

'policy' for multiple versions of same software in EPEL
 
On Fri, Oct 12, 2012 at 4:53 PM, Kevin Fenzi <kevin@scrye.com> wrote:
> On Wed, 10 Oct 2012 13:13:41 -0500
> Greg Swift <gregswift@gmail.com> wrote:
>
>> So... I've paid attention to the conversations around this because i
>> was a long time zabbix user, so it affected me in that I had to build
>> my own 'latest' packages usually or download from the maintainer's
>> personal repository. If I remember correctly it has also been
>> discussed around lots of web apps like bugzilla as well.
>
> Yeah.
>
> There's a lot of apps out there that have a different release cycle
> that RHEL has, so we have to try and adjust to that. Keeping in mind
> that most people who are using RHEL don't like things changing very
> much.

I'm all for that. Technically its one of the benefits of them being
different package namespaces that conflict, you won't get a change you
don't force with intent :)

> ...snip...
>
>> So the two scenarios I'm looking at:
>>
>> 1: collectd [3] - to make version 5 available in epel5/6 will have to
>> submit collectd5 package. Most of the work is done, but right now the
>> created package 'conflicts' due to duplicate library files and the
>> perl-Collectd module needing to be renamed. I can usually package up
>> software pretty readily, and I don't know how to do what is needed to
>> do this without more guidance (more admin than dev). Because of what
>> the software is, I'd imagine most people are running either version 4
>> or version 5. Some people might be running both environments from the
>> server side (separate collectors), but aren't likely to have a
>> monitored (client) system active in both.
>
> Right. I think this may be something we want to ask the Fedora
> Packaging folks (who live on the packaging list) about.

good plan

> The main problem with conflicts is that it's something that is detected
> by yum at the 'test' stage. It means you have chosen, downloaded a
> bunch of stuff and then yum tells you, "WOAH, these confict, fix it and
> try again". This is not very friendly. If you do this in the installer
> it's even worse.

that is unfortunate

> In this case I guess your reasoning makes sense to me, people are
> unlikely to want to run both at the same time on clients. However, on
> servers they might... what parts of them would conflict?

hmm... still tough to justify running simultaneous on the same server.
Maybe I've just always had machines available (both virtual and
physical) . That being said, i wonder if we make the packages support
--prefix if the customer can override and make it work?

I just don't think we should spend a lot of time and resources trying
to make something work for the sub1% that are doing something uncommon
and special in the first place.

However, If one of the people that wants that wants to chip in and
provide use case, testing, and preferably patches that would be
awesome.

>> 2: rubygem-rspec (no associated bugzilla entry that I am aware of yet)
>> - to make rspec-puppet available in epel 5/6 version 2 of rspec needs
>> to be made available. I assume this means that the same general
>> concept of rspec2 package needing to be initiated begins. With this
>> one there appears to be way more impact as there are at least 3
>> packages that build on top of rspec currently. [4] Because this is
>> more of a library set of packages, and most of those packages perform
>> different functionality for rspec that may not always be for the same
>> end use cases it makes conflicts a harder possibility. So i'd imagine
>> either a) have to do a parallel installable rspec2 release of all of
>> them that conflicts so that the 'gems' themselves don't need to be
>> adjusted or b) adjust the entire rubygem so that it behaves as rspec2
>> and make the other gems use rspec2 rather than rspec.
>
> Well, this is a reasoning for rspec2 to be completely parallel
> installable. Can't those things that wish continue to use rspec1?
> Or would that lead to mixing them both since they are in the same
> stack?

They are decidedly incompatible versions, but definitely the same
stack and namespace. since they run on the same version of ruby, its
not like we get a separation that way.

For any EPEL users that use rubygem-rspec (which has nothing built
against it.. see footnote in previous message), the rubygem-rspec2
would be a conflict and non-obsolete so they could keep on keeping on,
even update if there was one (which I don't believe there is or ever
will be based on rspec state).

With this example, i don't see why you'd want both versions. However,
I know that is not always going to hold true.

I guess maybe a series of scenarios being documented with suggestions
on handling would be best?

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list


All times are GMT. The time now is 09:30 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.