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....
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
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?
On Fri, 12 Oct 2012 22:35:03 -0500 Greg Swift gregswift@gmail.com wrote:
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 :)
Right. It would be something end users would have to specifically do...
'yum remove foo' 'yum install foo2'
...snip...
Right. I think this may be something we want to ask the Fedora Packaging folks (who live on the packaging list) about.
good plan
Can you post over there about this and look for feedback?
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
yes, it sure is. ;(
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.
True. I do see your point...
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.
yeah.
...snip...
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?
yeah. That would at least help us see what all the combos do/are.
kevin
...snip...
Right. I think this may be something we want to ask the Fedora Packaging folks (who live on the packaging list) about.
good plan
Can you post over there about this and look for feedback?
I am going to. my procrastination excuse was that I was hoping to hear from at least one more person before I did in case there was more feedback.
-greg
On Wed, Oct 17, 2012 at 12:57:31PM -0500, Greg Swift wrote:
...snip...
Right. I think this may be something we want to ask the Fedora Packaging folks (who live on the packaging list) about.
good plan
Can you post over there about this and look for feedback?
I am going to. my procrastination excuse was that I was hoping to hear from at least one more person before I did in case there was more feedback.
There are quite a few reasons to avoid Conflicts. Some of them are listed on the Conflicts wiki page but there are others as well. For instance, in Fedora, we need to make the effort to be porting software forward to newer versions of their dependencies rather than maintaining extra packages for backwards compatibility. But EPEL doesn't need to play by the same rules if they don't want to.
There's a basic question of cost and benefit. For Fedora, with its shorter time to EOL, the costs of a no-Conflicts policy are less than in EPEL where your base platform is going to be available for years. Just bear in mind that you're going to be maintaining those compat packages for years as well. So the costs of allowing Conflicts are also higher.
For your two initial examples, I think that you'd want to be careful about allowing conflicts but might be able to justify it in one of the cases. You need to ask yourself: "Would any user want to install both versions of this package at the same time?" For an application, this may be no. For a library, this is almost always going to be yes. To me that rules rubygem-rspec right out as a good case for Conflicts. Collectd is also libraries but the case could be made that they'd be coupled to whatever version of collectd is running on the system. So you might be able to make the case there. (But do think about things like -- what if a user has some boxes running collectd5 and others collectd4. If these libraries were parallel installable would they enable the user to query information from both sets of boxes?)
-Toshio
On Thu, Oct 18, 2012 at 10:38 AM, Toshio Kuratomi a.badger@gmail.com wrote:
On Wed, Oct 17, 2012 at 12:57:31PM -0500, Greg Swift wrote:
...snip...
Right. I think this may be something we want to ask the Fedora Packaging folks (who live on the packaging list) about.
good plan
Can you post over there about this and look for feedback?
I am going to. my procrastination excuse was that I was hoping to hear from at least one more person before I did in case there was more feedback.
There are quite a few reasons to avoid Conflicts. Some of them are listed on the Conflicts wiki page but there are others as well. For instance, in Fedora, we need to make the effort to be porting software forward to newer versions of their dependencies rather than maintaining extra packages for backwards compatibility. But EPEL doesn't need to play by the same rules if they don't want to.
Ya. That's where it gets interesting. I completely agree with all of the points towards Fedora, but EPEL is definitely a different beast. Its that weird limbo between rolling release and very long term support but not being paid to care about it. (Although I guess most contributors are kinda paid because they are likely doing it for their dayjob, but that likely rarely includes caring about other people's long term needs).
The EPEL philosophy provides a basic set of guidelines. http://fedoraproject.org/wiki/History_and_Philosophy_of_EPEL#Philosophy
1: Never replace or interfere with RHEL packages 2: Packages should be supported for the life of related RHEL project 3: No manual update process or procedures 4: During 'stable' EPEL cycle package shouldn't update in a way that changes user experience or does more than just bugfixes.
A few thoughts on these:
1: That has become complicated.. i know there is a very long thread about the scenario where Red Hat buys and commercializes a tool that was already in EPEL. 2: Nice concept, and we can keep them around but 'supported' depends on your definition... see below 3: This is great for 'no suprises' but what about the people where an upgrade is not a surprise? 4: Makes sense.
Seems to me that how people seem to want to use EPEL should also be considered. I just watched one of the PuppetConf presentations while I was writing this and heard something along the lines of 'use FPM because getting up to date software in something like EPEL is too hard'. How does that help when the only thing stopping that new version being available is a poor upgrade path for the software in packaging policy (including recommended methods)?
There's a basic question of cost and benefit. For Fedora, with its shorter time to EOL, the costs of a no-Conflicts policy are less than in EPEL where your base platform is going to be available for years. Just bear in mind that you're going to be maintaining those compat packages for years as well. So the costs of allowing Conflicts are also higher.
The cost of maintaining the compat packages can be huge, but the reality is that for most of the ones we are talking about replacing the likelyhood of an update diminishes every month as most of the new packages are for software that has been/will be left in dust by upstream. If there is a valid upstream release for security reasons, that older package can still be updated.
Some examples of last update dates from upstream for existing packages in EPEL: rspec 1.3 - Apr 2011 collectd 4 - Mar 2011 django 1.3 - Oct 2012 (security update, 1.4 is current stable branch) zabbix 1.6 (rhel5) - Mar 2010 zabbix 1.8 (rhel6) - Aug 2012 (likely last non-security update, 2.0 branch is current stable branch) bugzilla 3.4 - Feb 2012 (security update, branch has since closed) mediawiki116 1.16 - May 2011 (1.17 release was discontinued Jun 2012) mediawiki119 1.19 - Sep 2012 (based on current average release cycle I give this until mid-2013)
The mediawiki are the only ones that are named including the version. I didn't want to browse the entire list of packages, so these are just the ones that popped out at me.
The ones that are within the 2012 year don't seem to bad right now. But what about in 2017 (rhel5) or 2020 (rhel6) when non-extended lifecycle of that release ends?
For your two initial examples, I think that you'd want to be careful about allowing conflicts but might be able to justify it in one of the cases. You need to ask yourself: "Would any user want to install both versions of this package at the same time?" For an application, this may be no. For a library, this is almost always going to be yes. To me that rules rubygem-rspec right out as a good case for Conflicts. Collectd is also libraries but the case could be made that they'd be coupled to whatever version of collectd is running on the system. So you might be able to make the case there. (But do think about things like -- what if a user has some boxes running collectd5 and others collectd4. If these libraries were parallel installable would they enable the user to query information from both sets of boxes?)
So... I agree with the concept of compat packages. Except when it requires the package maintainer to patch the code (aren't we against non-upstream accepted patches?) and create a non-standard installation of the software. In ruby (or python, or perl), if anyone that wants to package or deploy software that uses the newer version has to edit that module from including 'module' to 'moduleVERSION' have we made a usable package?
For collectd, I'd imagine that if you have both 4 and 5, you have servers for both 4 and 5 as collectors, and you'd just run your bits on each. Having both on one box would enable you to query both systems, but what is the incentive to try and maintain this use case for the packagers?
Since I started writing this there has been another thread about bringing Puppet current. And well...
Here are two options as I see it (not including continuing on in this inconsistent manner)
- New EPEL package requirement... package name _must_ contain version number based on upstream's abi/api compatability policy.
Okay.. move past the initial 'bleh' reaction and think about it.
Then.. take the recommendation one of my co-workers provided:
- A new EPEL repository path. EPEL-rolling (or current or whatever). You can enable this repository if you want to stay with current packages.
And if you have stuph you don't want rolling forward you still have several choices:
1: Manage your own local repo collection 2: Set excludes on those packages 3: Just leave the rolling repo disabled except for when you need to do an update.
I've a few other thoughts on this but don't want to over load this already full post.
-greg
Once upon a time, Greg Swift gregswift@gmail.com said:
Some examples of last update dates from upstream for existing packages in EPEL:
Another one for the list that I ran across recently is Bacula. EPEL 5 has Bacula 2.4.4, which is from January 2009 and is long EOL. As I understand it, 2.x clients aren't even supported by newer versions of the server (3.0, which is also EOL, 5.0, and 5.2 clients are supposed to work with newer/current servers).
RHEL 6 includes Bacula 5.0, which of course complicates things. I guess EPEL shouldn't have a newer version than later RHEL releases (especially in this case, since I don't know if a newer Bacula client is expected to work with an older server).
Internally, I'm packing 5.2 from Fedora as bacula52. I can't parallel install the different versions (although I don't think that would make much sense with this software).
On Mon, Oct 22, 2012 at 01:41:36PM -0500, Greg Swift wrote:
On Thu, Oct 18, 2012 at 10:38 AM, Toshio Kuratomi a.badger@gmail.com wrote:
For your two initial examples, I think that you'd want to be careful about allowing conflicts but might be able to justify it in one of the cases. You need to ask yourself: "Would any user want to install both versions of this package at the same time?" For an application, this may be no. For a library, this is almost always going to be yes. To me that rules rubygem-rspec right out as a good case for Conflicts. Collectd is also libraries but the case could be made that they'd be coupled to whatever version of collectd is running on the system. So you might be able to make the case there. (But do think about things like -- what if a user has some boxes running collectd5 and others collectd4. If these libraries were parallel installable would they enable the user to query information from both sets of boxes?)
So... I agree with the concept of compat packages. Except when it requires the package maintainer to patch the code (aren't we against non-upstream accepted patches?) and create a non-standard installation of the software. In ruby (or python, or perl), if anyone that wants to package or deploy software that uses the newer version has to edit that module from including 'module' to 'moduleVERSION' have we made a usable package?
Unfortunately, there's not a lot you can do about that (although many upstreams have worked on this problem off-and-on in various ways and it might be possible to work out something depending on the language you're dealing with. For instance, with python you're able to specify the version you want in one place in your application and then that's the version that will be used anywhere the library is imported).
If you replace a library with a new library that is incompatible, then you inconvenience anyone that is using the library that EPEL shipped with. If you don't update then you inconvenience anyone that is using or wants to use a newer version of the library.
The current policy of EPEL is geared towards people who have deployed based on what's currently in EPEL rather than those who want to deploy something new.
As for non-upstream patches... we are against them but not as much as other things. Non-upstream patches aren't a guideline in the Fedora packaging guideline, for instance. Keeping non-upstream patches to a minimum allows a package maintainer to do more work with their limited time. But there are things about packaging that sometimes require patching even if the upstream won't accept them. For instance, a patch to run against an older version of a language even though the upstream doesn't care about that version anymore. Figuring out how to utilize a different version of a library is just a short step away from that.
Here are two options as I see it (not including continuing on in this inconsistent manner)
- New EPEL package requirement... package name _must_ contain version
number based on upstream's abi/api compatability policy.
Okay.. move past the initial 'bleh' reaction and think about it.
Yep. Debian (which releases on a timeframe that's more like RHEL than Fedora) applies something like this to their C libraries.
Then.. take the recommendation one of my co-workers provided:
- A new EPEL repository path. EPEL-rolling (or current or whatever).
You can enable this repository if you want to stay with current packages.
I think a lot of people like this but no one is prepared to become the guy who's responsible for maintaining it. A new repository has both setup costs and long term maintainance costs. You can take a look at past list discussions for some ideas of those costs and then see if you can come up with a plan for how to meet the manpower requirements to make this work.
-Toshio
On Mon, Oct 22, 2012 at 2:53 PM, Toshio Kuratomi a.badger@gmail.com wrote:
On Mon, Oct 22, 2012 at 01:41:36PM -0500, Greg Swift wrote:
On Thu, Oct 18, 2012 at 10:38 AM, Toshio Kuratomi a.badger@gmail.com wrote:
For your two initial examples, I think that you'd want to be careful about allowing conflicts but might be able to justify it in one of the cases. You need to ask yourself: "Would any user want to install both versions of this package at the same time?" For an application, this may be no. For a library, this is almost always going to be yes. To me that rules rubygem-rspec right out as a good case for Conflicts. Collectd is also libraries but the case could be made that they'd be coupled to whatever version of collectd is running on the system. So you might be able to make the case there. (But do think about things like -- what if a user has some boxes running collectd5 and others collectd4. If these libraries were parallel installable would they enable the user to query information from both sets of boxes?)
So... I agree with the concept of compat packages. Except when it requires the package maintainer to patch the code (aren't we against non-upstream accepted patches?) and create a non-standard installation of the software. In ruby (or python, or perl), if anyone that wants to package or deploy software that uses the newer version has to edit that module from including 'module' to 'moduleVERSION' have we made a usable package?
Unfortunately, there's not a lot you can do about that (although many upstreams have worked on this problem off-and-on in various ways and it might be possible to work out something depending on the language you're dealing with. For instance, with python you're able to specify the version you want in one place in your application and then that's the version that will be used anywhere the library is imported).
If you replace a library with a new library that is incompatible, then you inconvenience anyone that is using the library that EPEL shipped with. If you don't update then you inconvenience anyone that is using or wants to use a newer version of the library.
The current policy of EPEL is geared towards people who have deployed based on what's currently in EPEL rather than those who want to deploy something new.
As for non-upstream patches... we are against them but not as much as other things. Non-upstream patches aren't a guideline in the Fedora packaging guideline, for instance. Keeping non-upstream patches to a minimum allows a package maintainer to do more work with their limited time. But there are things about packaging that sometimes require patching even if the upstream won't accept them. For instance, a patch to run against an older version of a language even though the upstream doesn't care about that version anymore. Figuring out how to utilize a different version of a library is just a short step away from that.
Okay... I took its mention in the guidelines as more of a strong recommendation, especially due to the 'If you think that your package should be exempt from part of the Guidelines, please bring the issue to the Fedora Packaging Committee'. Thanks for explaining that.
https://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_...
Here are two options as I see it (not including continuing on in this inconsistent manner)
- New EPEL package requirement... package name _must_ contain version
number based on upstream's abi/api compatability policy.
Okay.. move past the initial 'bleh' reaction and think about it.
Yep. Debian (which releases on a timeframe that's more like RHEL than Fedora) applies something like this to their C libraries.
I can see leaving the number off for the initial version, although in the long run for EPEL i think it'd be better to just number them all (ugly, I know... but considering RHEL support has gone from 7 years to 13 years, new packages are just a reality we are going to have to deal with).
Then.. take the recommendation one of my co-workers provided:
- A new EPEL repository path. EPEL-rolling (or current or whatever).
You can enable this repository if you want to stay with current packages.
I think a lot of people like this but no one is prepared to become the guy who's responsible for maintaining it. A new repository has both setup costs and long term maintainance costs. You can take a look at past list discussions for some ideas of those costs and then see if you can come up with a plan for how to meet the manpower requirements to make this work.
Do you have any thread names or search phrases to recommend? I found several threads back in 2007, which all appear to be early EPEL. Unfortunately, the audience and use of EPEL was much smaller then.
Its good to see that there was discussion about how to ensure this happens in the future. The repository directory structure does look like it can still handle the additional repository.
The question then becomes how would it fit into the koji/bodhi work flow. Is there a good reference for that? I've read the existing workflow document on Bodhi's wiki. It seems to me that there would have to be an additional package state, which may not directly plug into how bodhi currently works.
NEW ---> PENDING --> TESTING --> STABLE --> OBSOLETE --UNSTABLE--/------------/
With an UNSTABLE package also being able to push into STABLE if the STABLE package is no longer considered safe to run (that unsupported, or no available patch for security issue, or whatever.. would define a list)
Or the UNSTABLE package would just live in UNSTABLE unless it gets sent to OBSOLETE.
-greg
On Tue, 23 Oct 2012 09:45:21 -0500 Greg Swift gregswift@gmail.com wrote:
...snip...
Do you have any thread names or search phrases to recommend? I found several threads back in 2007, which all appear to be early EPEL. Unfortunately, the audience and use of EPEL was much smaller then.
Its good to see that there was discussion about how to ensure this happens in the future. The repository directory structure does look like it can still handle the additional repository.
The question then becomes how would it fit into the koji/bodhi work flow. Is there a good reference for that? I've read the existing workflow document on Bodhi's wiki. It seems to me that there would have to be an additional package state, which may not directly plug into how bodhi currently works.
NEW ---> PENDING --> TESTING --> STABLE --> OBSOLETE --UNSTABLE--/------------/
With an UNSTABLE package also being able to push into STABLE if the STABLE package is no longer considered safe to run (that unsupported, or no available patch for security issue, or whatever.. would define a list)
Or the UNSTABLE package would just live in UNSTABLE unless it gets sent to OBSOLETE.
Right. If you allow crossing the unstable/stable streams here it becomes very complicated.
This is where the start of all the work is... make git repos understand an unstable, make bodhi and mash and other compose tools understand it, have some way to report bugs about it (how do you set it in bugzilla?).
Lots of complicated questions and then lots of actual work. ;)
Even if you don't allow them to cross (ie, it's a completely seperate branch), it has still a bunch of work around the tools to get them working with it. Also, there will be problems where 'stable' stuff gets ignored or shoved down because people are more interested in the unstable part, etc.
Personally, I don't have the time or desire to do all this work. If a group of folks wanted to write up a complete plan here and offer to do the work, I would be happy to provide feedback and get talked into helping them out, but it would have to be a pretty good plan. :)
kevin
On Tue, Oct 23, 2012 at 10:43 AM, Kevin Fenzi kevin@scrye.com wrote:
...snip...
NEW ---> PENDING --> TESTING --> STABLE --> OBSOLETE --UNSTABLE--/------------/
With an UNSTABLE package also being able to push into STABLE if the STABLE package is no longer considered safe to run (that unsupported, or no available patch for security issue, or whatever.. would define a list)
Or the UNSTABLE package would just live in UNSTABLE unless it gets sent to OBSOLETE.
Right. If you allow crossing the unstable/stable streams here it becomes very complicated.
This is where the start of all the work is... make git repos understand an unstable, make bodhi and mash and other compose tools understand it, have some way to report bugs about it (how do you set it in bugzilla?).
Lots of complicated questions and then lots of actual work. ;)
Even if you don't allow them to cross (ie, it's a completely seperate branch), it has still a bunch of work around the tools to get them working with it. Also, there will be problems where 'stable' stuff gets ignored or shoved down because people are more interested in the unstable part, etc.
Between thinking about it more, reading the RHEL/EPEL conflict post again, and this post I'm inclined to go with the separate branch path.
Personally, I don't have the time or desire to do all this work. If a group of folks wanted to write up a complete plan here and offer to do the work, I would be happy to provide feedback and get talked into helping them out, but it would have to be a pretty good plan. :)
I have some cycles to work on this, but i would much rather have help, especially people that have more experience in these tools than I. This falls into the 'i either do it privately to benefit myself/company, or try and make it work in EPEL to benefit others that have expressed the need' category. Personally, I prefer to work upstream on it, but unless others are gonna hop on board its going to be much easier in the short term for me to go the private route.
-greg
On Wed, Oct 24, 2012 at 9:30 AM, Greg Swift gregswift@gmail.com wrote:
On Tue, Oct 23, 2012 at 10:43 AM, Kevin Fenzi kevin@scrye.com wrote:
...snip...
NEW ---> PENDING --> TESTING --> STABLE --> OBSOLETE --UNSTABLE--/------------/
With an UNSTABLE package also being able to push into STABLE if the STABLE package is no longer considered safe to run (that unsupported, or no available patch for security issue, or whatever.. would define a list)
Or the UNSTABLE package would just live in UNSTABLE unless it gets sent to OBSOLETE.
Right. If you allow crossing the unstable/stable streams here it becomes very complicated.
This is where the start of all the work is... make git repos understand an unstable, make bodhi and mash and other compose tools understand it, have some way to report bugs about it (how do you set it in bugzilla?).
Lots of complicated questions and then lots of actual work. ;)
Even if you don't allow them to cross (ie, it's a completely seperate branch), it has still a bunch of work around the tools to get them working with it. Also, there will be problems where 'stable' stuff gets ignored or shoved down because people are more interested in the unstable part, etc.
Between thinking about it more, reading the RHEL/EPEL conflict post again, and this post I'm inclined to go with the separate branch path.
Personally, I don't have the time or desire to do all this work. If a group of folks wanted to write up a complete plan here and offer to do the work, I would be happy to provide feedback and get talked into helping them out, but it would have to be a pretty good plan. :)
I have some cycles to work on this, but i would much rather have help, especially people that have more experience in these tools than I. This falls into the 'i either do it privately to benefit myself/company, or try and make it work in EPEL to benefit others that have expressed the need' category. Personally, I prefer to work upstream on it, but unless others are gonna hop on board its going to be much easier in the short term for me to go the private route.
I think users of the EL ecosystem would really like a repo with updated software etc, but if getting EPEL off the ground is any indication, you'll have very low participation from a development and infrastructure side, a *lot* of infrastructure needs. It took months (possibly years) to even find broken deps in EPEL due to lack of time/focus from the EPEL community, and that's a pretty simple task.
Also, people who change jobs etc who were at one time very able to help out suddenly can have a lot less time. (Ask me how I know :) )
If you could get 10-12 people willing to do the infrastructure work (like a SIG etc) it might be viable setup. Outside of that private repos (or even public but not on Fedora properties) might be the way to go.
-greg
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Wed, Oct 24, 2012 at 11:51 AM, Michael Stahnke stahnma@puppetlabs.com wrote:
On Wed, Oct 24, 2012 at 9:30 AM, Greg Swift gregswift@gmail.com wrote:
On Tue, Oct 23, 2012 at 10:43 AM, Kevin Fenzi kevin@scrye.com wrote:
...snip...
NEW ---> PENDING --> TESTING --> STABLE --> OBSOLETE --UNSTABLE--/------------/
With an UNSTABLE package also being able to push into STABLE if the STABLE package is no longer considered safe to run (that unsupported, or no available patch for security issue, or whatever.. would define a list)
Or the UNSTABLE package would just live in UNSTABLE unless it gets sent to OBSOLETE.
Right. If you allow crossing the unstable/stable streams here it becomes very complicated.
This is where the start of all the work is... make git repos understand an unstable, make bodhi and mash and other compose tools understand it, have some way to report bugs about it (how do you set it in bugzilla?).
Lots of complicated questions and then lots of actual work. ;)
Even if you don't allow them to cross (ie, it's a completely seperate branch), it has still a bunch of work around the tools to get them working with it. Also, there will be problems where 'stable' stuff gets ignored or shoved down because people are more interested in the unstable part, etc.
Between thinking about it more, reading the RHEL/EPEL conflict post again, and this post I'm inclined to go with the separate branch path.
Personally, I don't have the time or desire to do all this work. If a group of folks wanted to write up a complete plan here and offer to do the work, I would be happy to provide feedback and get talked into helping them out, but it would have to be a pretty good plan. :)
I have some cycles to work on this, but i would much rather have help, especially people that have more experience in these tools than I. This falls into the 'i either do it privately to benefit myself/company, or try and make it work in EPEL to benefit others that have expressed the need' category. Personally, I prefer to work upstream on it, but unless others are gonna hop on board its going to be much easier in the short term for me to go the private route.
I think users of the EL ecosystem would really like a repo with updated software etc, but if getting EPEL off the ground is any indication, you'll have very low participation from a development and infrastructure side, a *lot* of infrastructure needs. It took months (possibly years) to even find broken deps in EPEL due to lack of time/focus from the EPEL community, and that's a pretty simple task.
Also, people who change jobs etc who were at one time very able to help out suddenly can have a lot less time. (Ask me how I know :) )
yea... i'm well aware of that pitfall.. i've suffered from it as well
If you could get 10-12 people willing to do the infrastructure work (like a SIG etc) it might be viable setup. Outside of that private repos (or even public but not on Fedora properties) might be the way to go.
So.. just spent like 30m digging through the wiki and somehow did not stumble across the 'how to start a sig' page. anyone got a pointer?
On Wed, 24 Oct 2012 15:57:43 -0500 Greg Swift gregswift@gmail.com wrote:
...snip...
So.. just spent like 30m digging through the wiki and somehow did not stumble across the 'how to start a sig' page. anyone got a pointer?
Just announce you exist and start meeting and working on things. ;)
There is not a formal process.
Although in this case I don't know if SIG is really the right thing to call a group working on a specific subset of EPEL stuff.
Might be more productive to try and get regular EPEL meetings going again, etc. (I've tried, but can't seem to find a time when many people are able to attend).
kevin
On Wed, 24 Oct 2012 11:30:53 -0500 Greg Swift gregswift@gmail.com wrote:
Between thinking about it more, reading the RHEL/EPEL conflict post again, and this post I'm inclined to go with the separate branch path.
I'm still leary of the seperate branch. ;)
Even aside from more work I worry that we will run into several possible problems:
- New unstable branch is too unstable. Ie, people will enable that and yum upgrade and it breaks them and they will be unhappy. Even if the expectation of the branch is that it will be not stable.
- Old branch gets forgotten about... ie, maintainer pushes new and ignores bugs/security issues on old branch because they now don't have the same incentive to make it work. ;(
- Extra confusion around tools and branch changes...
I have some cycles to work on this, but i would much rather have help, especially people that have more experience in these tools than I. This falls into the 'i either do it privately to benefit myself/company, or try and make it work in EPEL to benefit others that have expressed the need' category. Personally, I prefer to work upstream on it, but unless others are gonna hop on board its going to be much easier in the short term for me to go the private route.
Perhaps it would help if you could spell out exactly what things you need for yourself/company and we could try and figure out a better way to get them... if it's just a few packages that must be newer, perhaps a side repo would be best.
kevin
On Wed, Oct 24, 2012 at 2:40 PM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 24 Oct 2012 11:30:53 -0500 Greg Swift gregswift@gmail.com wrote:
Between thinking about it more, reading the RHEL/EPEL conflict post again, and this post I'm inclined to go with the separate branch path.
I'm still leary of the seperate branch. ;)
Even aside from more work I worry that we will run into several possible problems:
- New unstable branch is too unstable. Ie, people will enable that and yum upgrade and it breaks them and they will be unhappy. Even if the expectation of the branch is that it will be not stable.
So... going back to my REPEL name recommendation ;)
Okay... seriously though. Fedora has the same issue. Fedora is not stable. Doesn't claim to be. But people still install it and expect it to be. I don't see us actually changing what Fedora is just because of that. (lots of talk on occasion and i guess maybe there is a action item I haven't heard of...)
- Old branch gets forgotten about... ie, maintainer pushes new and ignores bugs/security issues on old branch because they now don't have the same incentive to make it work. ;(
That is a problem. However, its already the case from what I've observed. The old packages stagnate and the users move to an internal/separate repository or start a separate package path, or in a few cases just update the package.
- Extra confusion around tools and branch changes...
To me the biggest set of confusion around this whole thing is that it is inconsistent and not set forth in a policy. Right now the policy ends up being 'well.. don't break the customer, otherwise figure it out'.
If the policy was:
EPEL is a slow moving, safe to upgrade, but not always safe from a security standpoint after X amount of time repository.
REPEL is a faster moving repository that may include updates that require manual intervention. Use at your own risk, but you'll probably have more secure updates since its staying current.
or going to Ken's suggestion:
EPEL is a slower moving repository. In line with RHEL dot releases new packages maybe released that require manual intervention to work post install, however this is due to the need to keep software secure and current. As long as a release branch is receiving updates from upstream, that package will be able to update safely. Once upstream has EOL'd the tool it will be updated based on an assessment of the tool's newer releases. To stay aware of these potential updates we do X, Y, and Z to notify users. You can protect yourself from the change by placing the package in your exclude list per these instructions.
I have some cycles to work on this, but i would much rather have help, especially people that have more experience in these tools than I. This falls into the 'i either do it privately to benefit myself/company, or try and make it work in EPEL to benefit others that have expressed the need' category. Personally, I prefer to work upstream on it, but unless others are gonna hop on board its going to be much easier in the short term for me to go the private route.
Perhaps it would help if you could spell out exactly what things you need for yourself/company and we could try and figure out a better way to get them... if it's just a few packages that must be newer, perhaps a side repo would be best.
So what got me going on this _this time_ was wanting to have rspec-puppet and collectd5 in EPEL. Which led to the need for rspec to be updated to rspec2 (for EPEL5/6). Combine that with my past interest in bugzilla, zabbix, puppet, and a few other projects. Because of that I thought it would be nice to try and address the obvious overall issue rather than just get my two packages taken care of.
-greg
On Wed, 24 Oct 2012 16:23:28 -0500 Greg Swift gregswift@gmail.com wrote:
...snip...
So... going back to my REPEL name recommendation ;)
Okay... seriously though. Fedora has the same issue. Fedora is not stable. Doesn't claim to be. But people still install it and expect it to be. I don't see us actually changing what Fedora is just because of that. (lots of talk on occasion and i guess maybe there is a action item I haven't heard of...)
Sure.
- Old branch gets forgotten about... ie, maintainer pushes new and ignores bugs/security issues on old branch because they now don't have the same incentive to make it work. ;(
That is a problem. However, its already the case from what I've observed. The old packages stagnate and the users move to an internal/separate repository or start a separate package path, or in a few cases just update the package.
Perhaps, but I suspect many also just continue blindly using the old packages. ;(
- Extra confusion around tools and branch changes...
To me the biggest set of confusion around this whole thing is that it is inconsistent and not set forth in a policy. Right now the policy ends up being 'well.. don't break the customer, otherwise figure it out'.
If the policy was:
EPEL is a slow moving, safe to upgrade, but not always safe from a security standpoint after X amount of time repository.
Yeah, I dislike that, because how is someone to know? check the other repo for a newer version? But that might be due to features, not security...
REPEL is a faster moving repository that may include updates that require manual intervention. Use at your own risk, but you'll probably have more secure updates since its staying current.
or going to Ken's suggestion:
EPEL is a slower moving repository. In line with RHEL dot releases new packages maybe released that require manual intervention to work post install, however this is due to the need to keep software secure and current. As long as a release branch is receiving updates from upstream, that package will be able to update safely. Once upstream has EOL'd the tool it will be updated based on an assessment of the tool's newer releases. To stay aware of these potential updates we do X, Y, and Z to notify users. You can protect yourself from the change by placing the package in your exclude list per these instructions.
Yeah, I like that better personally. But it also has it's issues. ;)
kevin
On Tue, Oct 23, 2012 at 09:45:21AM -0500, Greg Swift wrote:
On Mon, Oct 22, 2012 at 2:53 PM, Toshio Kuratomi a.badger@gmail.com wrote:
As for non-upstream patches... we are against them but not as much as other things. Non-upstream patches aren't a guideline in the Fedora packaging guideline, for instance. Keeping non-upstream patches to a minimum allows a package maintainer to do more work with their limited time. But there are things about packaging that sometimes require patching even if the upstream won't accept them. For instance, a patch to run against an older version of a language even though the upstream doesn't care about that version anymore. Figuring out how to utilize a different version of a library is just a short step away from that.
Okay... I took its mention in the guidelines as more of a strong recommendation, especially due to the 'If you think that your package should be exempt from part of the Guidelines, please bring the issue to the Fedora Packaging Committee'. Thanks for explaining that.
https://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_...
Ah -- yeah, that's a SHOULD guideline. Shoulds are best practices that we mention in the guidelines but it's a sign there's a lot more leeway as to what's acceptable. It usually means that there's good reasons to follow it and good reasons not to. When reviewing a package or looking at an existing package there can be valid reasons that the spec file doesn't conform to what the guideline says you should do.
-Toshio
On Tue, Oct 23, 2012 at 09:45:21AM -0500, Greg Swift wrote:
Do you have any thread names or search phrases to recommend? I found several threads back in 2007, which all appear to be early EPEL. Unfortunately, the audience and use of EPEL was much smaller then.
Here's one of the most informative posts from a past thread: https://www.redhat.com/archives/epel-devel-list/2012-May/msg00164.html
I see that Kevin has replied to this post as well with some of the higher level design considerations as well.
-Toshio
On Tue, Oct 23, 2012 at 12:27 PM, Toshio Kuratomi a.badger@gmail.com wrote:
On Tue, Oct 23, 2012 at 09:45:21AM -0500, Greg Swift wrote:
Do you have any thread names or search phrases to recommend? I found several threads back in 2007, which all appear to be early EPEL. Unfortunately, the audience and use of EPEL was much smaller then.
Here's one of the most informative posts from a past thread: https://www.redhat.com/archives/epel-devel-list/2012-May/msg00164.html
thanks.. i remember trying to keep up with that thread initially, but didn't recall it getting to a discussion about repos.
I see that Kevin has replied to this post as well with some of the higher level design considerations as well.
(from that thread:)
A partial list of what we would need to do to add a repo:
Patch bodhi to know about the new repo, what requirements it would have. If it would have a updates-testing version and how to promote to updates.
Add a koji tag for the builds.
Modify the fedora git processing scripts to allow branches to be made for this repo.
Update mash and such to create the repo(s).
Process all the packages that would need to be added.
Add components to bugzilla for the new repo/channels/packages.
If an additional repo is decided to be the way to go, what would it take to develop a mostly 'complete' list along with a list of existing howtos or subject matter experts that can be referenced by the poor soul(s) who volunteer to do the work?
And I'm sure there's other issues... it would not be at all easy, and I would prefer to avoid it.
understandably. although at this point I'm wondering a few things:
1: since multiple bits have brought this up and no one has come up with a better solution, is this the way we need to go?
2: would a single EPEL-supplemental/rolling/fubar meet the needs of both of these paths?
3: is it possible to do the numbered packages in the same git repositories without creating a whole separate package path? is it reasonable?
-greg
On Wed, 24 Oct 2012 11:25:10 -0500 Greg Swift gregswift@gmail.com wrote:
If an additional repo is decided to be the way to go, what would it take to develop a mostly 'complete' list along with a list of existing howtos or subject matter experts that can be referenced by the poor soul(s) who volunteer to do the work?
Hard to say until we had such a list. ;)
And I'm sure there's other issues... it would not be at all easy, and I would prefer to avoid it.
understandably. although at this point I'm wondering a few things:
1: since multiple bits have brought this up and no one has come up with a better solution, is this the way we need to go?
I'm still not sure. ;)
2: would a single EPEL-supplemental/rolling/fubar meet the needs of both of these paths?
I don't know. I'd love to hear from those that have cases not handled by current EPEL.
3: is it possible to do the numbered packages in the same git repositories without creating a whole separate package path? is it reasonable?
I don't know. I guess it would need to be 'epel6-rolling' and 'epel5-rolling' as seperate branches in git.
kevin
On Wed, Oct 24, 2012 at 2:41 PM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 24 Oct 2012 11:25:10 -0500 Greg Swift gregswift@gmail.com wrote:
If an additional repo is decided to be the way to go, what would it take to develop a mostly 'complete' list along with a list of existing howtos or subject matter experts that can be referenced by the poor soul(s) who volunteer to do the work?
Hard to say until we had such a list. ;)
Fun ;)
So that was partially intended as "who not already responding do i need to poke and prod to try and find this out?"
And if you are one of those wonderful people, consider yourself poked and prodded :)
And I'm sure there's other issues... it would not be at all easy, and I would prefer to avoid it.
understandably. although at this point I'm wondering a few things:
1: since multiple bits have brought this up and no one has come up with a better solution, is this the way we need to go?
I'm still not sure. ;)
2: would a single EPEL-supplemental/rolling/fubar meet the needs of both of these paths?
I don't know. I'd love to hear from those that have cases not handled by current EPEL.
me too
3: is it possible to do the numbered packages in the same git repositories without creating a whole separate package path? is it reasonable?
I don't know. I guess it would need to be 'epel6-rolling' and 'epel5-rolling' as seperate branches in git.
so ... *insert tongue in cheek* i've now decided we should use REPEL as the name. maybe that would resolve the 'i used it and through it was stable' issue *remove tongue from cheek*
On Fri, Oct 12, 2012 at 3: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.
Here's an alternative proposal I've been mentally kicking around...
Red Hat itself sometimes rebases software between minor point releases (eg 6.0 to 6.1). Could we allow EPEL maintainers to push "non-backwards-compatible updates" at specific dates that match RHEL's minor point release schedule?
As Greg points out, EPEL is essentially a rolling release today anyway. This would just provide a bit more structure to the rolling. Also, I'm hoping this would not require as much infrastructure work on EPEL's side.
- Ken
On Wed, Oct 24, 2012 at 2:08 PM, Ken Dreyer ktdreyer@ktdreyer.com wrote:
On Fri, Oct 12, 2012 at 3: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.
Here's an alternative proposal I've been mentally kicking around...
Red Hat itself sometimes rebases software between minor point releases (eg 6.0 to 6.1). Could we allow EPEL maintainers to push "non-backwards-compatible updates" at specific dates that match RHEL's minor point release schedule?
As Greg points out, EPEL is essentially a rolling release today anyway. This would just provide a bit more structure to the rolling. Also, I'm hoping this would not require as much infrastructure work on EPEL's side.
i can get behind this concept.
On Wed, Oct 24, 2012 at 01:08:01PM -0600, Ken Dreyer wrote:
Red Hat itself sometimes rebases software between minor point releases (eg 6.0 to 6.1). Could we allow EPEL maintainers to push "non-backwards-compatible updates" at specific dates that match RHEL's minor point release schedule?
+1 in theory, modulo the realities of getting it working.
---------- Forwarded message ---------- From: Matthew Miller mattdm@fedoraproject.org Date: Wed, Oct 24, 2012 at 5:44 PM Subject: Re: 'policy' for multiple versions of same software in EPEL To: EPEL development disccusion epel-devel-list@redhat.com
On Wed, Oct 24, 2012 at 01:08:01PM -0600, Ken Dreyer wrote:
Red Hat itself sometimes rebases software between minor point releases (eg 6.0 to 6.1). Could we allow EPEL maintainers to push "non-backwards-compatible updates" at specific dates that match RHEL's minor point release schedule?
+1 in theory, modulo the realities of getting it working.
This becomes difficult in reality. Or at least was when RHEL would bump, but other EL variants hadn't updated yet. I specifically remember this being a problem with libevent in the past. Would EPEL allow breaking changes when RHEL moves or when other EL variants move? Is there an open-window timeframe etc?
In general, I'm in favor of being able to update, as a volunteer maintaining anything for 10 years is pretty unreasonable, but expectations for the users need to be set accordingly.
-- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mattdm@fedoraproject.org
_______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
I didn't say everything attributed to me below. I don't necessarily disagree or agree right now, just wanted to note that only the first line ("+1 in theory..." is actually my words.)
On Fri, Oct 26, 2012 at 10:03:33AM -0700, Michael Stahnke wrote:
---------- Forwarded message ---------- From: Matthew Miller mattdm@fedoraproject.org Date: Wed, Oct 24, 2012 at 5:44 PM Subject: Re: 'policy' for multiple versions of same software in EPEL To: EPEL development disccusion epel-devel-list@redhat.com
On Wed, Oct 24, 2012 at 01:08:01PM -0600, Ken Dreyer wrote:
Red Hat itself sometimes rebases software between minor point releases (eg 6.0 to 6.1). Could we allow EPEL maintainers to push "non-backwards-compatible updates" at specific dates that match RHEL's minor point release schedule?
+1 in theory, modulo the realities of getting it working.
This becomes difficult in reality. Or at least was when RHEL would bump, but other EL variants hadn't updated yet. I specifically remember this being a problem with libevent in the past. Would EPEL allow breaking changes when RHEL moves or when other EL variants move? Is there an open-window timeframe etc?
In general, I'm in favor of being able to update, as a volunteer maintaining anything for 10 years is pretty unreasonable, but expectations for the users need to be set accordingly.
-- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mattdm@fedoraproject.org
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Fri, Oct 26, 2012 at 12:03 PM, Michael Stahnke stahnma@puppetlabs.com wrote:
---------- Forwarded message ---------- From: Matthew Miller mattdm@fedoraproject.org
On Wed, Oct 24, 2012 at 01:08:01PM -0600, Ken Dreyer wrote: Red Hat itself sometimes rebases software between minor point releases (eg 6.0 to 6.1). Could we allow EPEL maintainers to push "non-backwards-compatible updates" at specific dates that match RHEL's minor point release schedule?
+1 in theory, modulo the realities of getting it working.
This becomes difficult in reality. Or at least was when RHEL would bump, but other EL variants hadn't updated yet. I specifically remember this being a problem with libevent in the past. Would EPEL allow breaking changes when RHEL moves or when other EL variants move? Is there an open-window timeframe etc?
And it also just occurred to me that the RHEL stops doing this kind of update mid lifecycle. And its later in the lifecycle that the maintainers are going to want to upgade, so that throws another wrench in the works.
In general, I'm in favor of being able to update, as a volunteer maintaining anything for 10 years is pretty unreasonable, but expectations for the users need to be set accordingly.
+1
- greg
(message indenting updated to reflect matt miller's e-mail ;)
This plan has also come up before. ;)
Pros:
- Gives us a 6monthish time to retire/update things if needed.
- Gives us a clear place we can tell users: "Things might break here, please do lots more testing, etc"
- lets us do incompatible upgrades if we need to.
Cons:
- We never know when exactly a point release is going to appear until it does. RH never announces them in advance. So, might lead to scrambling. It's pretty unlikely we could push those updates the same day as the point release... so when would we? would they go through testing as usual?
- Do we want for CentOS/SL/whatever to release their version? If not, it could lead to breakage for users who use epel with those until they do.
- Once we push those incompatible ones that require the new point release, does that just leave people who are on an older one out in the cold? Or they get the updates and it breaks them even though they didn't apply the point release?
kevin
Note1: I do *not* use CentOS nor am I it's advocate. Take that into account reading below [rough] ideas. I am however RHEL subscriber in the office and Fedora user at home.
Note2: I may be missing certain aspects of inter-distribution relations thus please don't throw heavy objects my way if I start sounding like heritic around here ;)
On October 29, 2012 12:52:01 Kevin Fenzi wrote:
Cons:
- We never know when exactly a point release is going to appear until it does. RH never announces them in advance. So, might lead to scrambling. It's pretty unlikely we could push those updates the same day as the point release... so when would we? would they go through testing as usual?
Maybe aligning more with CenOS schedule? They end up trailing RHEL as well so whatever time they get before pushing "the latest" may be enough for EPEL?
- Do we want for CentOS/SL/whatever to release their version? If not, it could lead to breakage for users who use epel with those until they do.
question from the different dimension: would it not make sense to merge CentOS[-extras] community with EPEL as two essentially are trying to compliment (augument) RHEL with more software? Was that ever considered in the past? Not trying to insigate, but rather suggest alternative approaches to above model.
- Once we push those incompatible ones that require the new point release, does that just leave people who are on an older one out in the cold? Or they get the updates and it breaks them even though they didn't apply the point release?
Once upon a time, Dmitry Makovey dmitry@athabascau.ca said:
Maybe aligning more with CenOS schedule? They end up trailing RHEL as well so whatever time they get before pushing "the latest" may be enough for EPEL?
CentOS has had some pretty long delays sometimes in the past, so I don't see that as a valid policy.
On Mon, Oct 29, 2012 at 12:52 PM, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Dmitry Makovey dmitry@athabascau.ca said:
Maybe aligning more with CenOS schedule? They end up trailing RHEL as well so whatever time they get before pushing "the latest" may be enough for EPEL?
CentOS has had some pretty long delays sometimes in the past, so I don't see that as a valid policy.
They've certainly worked to shorten that timeline. We could probably engage their core team and find out future plans as well, if so desired.
-- Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Mon, 29 Oct 2012, Michael Stahnke wrote:
On Mon, Oct 29, 2012 at 12:52 PM, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Dmitry Makovey dmitry@athabascau.ca said:
Maybe aligning more with CenOS schedule? They end up trailing RHEL as well so whatever time they get before pushing "the latest" may be enough for EPEL?
CentOS has had some pretty long delays sometimes in the past, so I don't see that as a valid policy.
They've certainly worked to shorten that timeline. We could probably engage their core team and find out future plans as well, if so desired.
I do not recommend synchronizing with any specific distribution.
-sv
On October 29, 2012 16:06:59 Seth Vidal wrote:
On Mon, 29 Oct 2012, Michael Stahnke wrote:
On Mon, Oct 29, 2012 at 12:52 PM, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Dmitry Makovey dmitry@athabascau.ca said:
Maybe aligning more with CenOS schedule? They end up trailing RHEL as well so whatever time they get before pushing "the latest" may be enough for EPEL?>>
CentOS has had some pretty long delays sometimes in the past, so I don't see that as a valid policy.
They've certainly worked to shorten that timeline. We could probably engage their core team and find out future plans as well, if so desired.
I do not recommend synchronizing with any specific distribution.
Seth, with all due respect, my understanding of EPEL is precisely bridge between releases of specific distributions (unless I got it wrong). It's aim is to bring "latest goodness" from current Fedora over to slower-paced RHEL/CentOS/SL.
Why would you recommend against synchronization with any distribution?
My reasons for bringing CenOS up: both groups (CentOS & EPEL) seem to suffer from the lack of man-power. Both groups target the same platform: RHEL and both are going through the same pains. Synchronizing work of such groups does sound "logical" as Mr. Spock would suggest.
P.S. not stirring things up but rather genuinely interested.
On Mon, 29 Oct 2012, Dmitry Makovey wrote:
Seth, with all due respect, my understanding of EPEL is precisely bridge between releases of specific distributions (unless I got it wrong). It's aim is to bring "latest goodness" from current Fedora over to slower-paced RHEL/CentOS/SL.
Not really. It's just building those pkgs which are not already in rhel for it and do so in a way which complies with fedora packaging policies.
Why would you recommend against synchronization with any distribution?
B/c there are many distros built on that base - and tying to one is implicitly blessing ONE distro.
And I think fedora officially blessing a rebuild of rhel is going to go over like a lead balloon.
-sv
On October 29, 2012 17:35:14 Seth Vidal wrote:
Why would you recommend against synchronization with any distribution?
B/c there are many distros built on that base - and tying to one is implicitly blessing ONE distro.
hmm. OK, makes sense.
And I think fedora officially blessing a rebuild of rhel is going to go over like a lead balloon.
I'm not suggesting that Fedora donates to/blesses CenOS builds, but rather having CentOS-Extras closer to EPEL. I imagine for some, who use CentOS-Extra and EPEL repos against RHEL* installs cross-listed packages would prove "difficult".
Anyway, I'm bidding for the cause I have limited interest in: my selfish goal was to find ways for EPEL to get more man-power to carry on. "Poaching" on the CeonOS side seemed reasonable. And I imagine situation could be viewed in reverse from CentOS side where they get some extra help (read: cross- polination) from EPEL.
I'll stop there :)
On Mon, Oct 29, 2012 at 12:52 PM, Kevin Fenzi kevin@scrye.com wrote:
This plan has also come up before. ;)
I didn't realize this had been brought up before. Do you have a link to the discussion? I've browsed through the EPEL archives and I didn't see something like this.
On Mon, Oct 29, 2012 at 12:52 PM, Kevin Fenzi kevin@scrye.com wrote:>
- We never know when exactly a point release is going to appear until it does. RH never announces them in advance. So, might lead to scrambling. It's pretty unlikely we could push those updates the same day as the point release... so when would we? would they go through testing as usual?
We could publish a policy that the "EPEL flag day" is two weeks after the day that RHEL ships a point release.
Pros:
* A maintainer can push an "incompatible update" into epel-testing on the day that RHEL ships, and then have their package hit epel-stable two weeks later on the agreed-upon flag day. (Of course, if a maintainer wanted to get their update into updates-testing sooner, that's fine too.)
* Easy to remember: "two weeks" is the same time as Bodhi testing.
* CentOS and SL are important, but we can't really affect the release schedules for these projects, so it's yet another one-way street. I think we have to just make a best effort. A consistent two week gap would these projects some leeway while not compromising on consistency.
Cons:
* We would need some coordination to ensure that the signing process happens on the day of RHEL's point release, and two weeks afterward. I'm not involved with the sigining task... hopefully this is not a huge deal?
* Technically we would have two release days (RHEL + EPEL) instead of one (RHEL).
- Once we push those incompatible ones that require the new point release, does that just leave people who are on an older one out in the cold? Or they get the updates and it breaks them even though they didn't apply the point release?
I'm having trouble picturing a scenario where this problem could happen in RHEL+EPEL. Can you explain more? (I'm not envisioning that these new packages would have dependencies on the redhat-release package version number; only that we would try to hit the dates on the calendar.)
- Ken
On Mon, 29 Oct 2012 13:39:26 -0600 Ken Dreyer ktdreyer@ktdreyer.com wrote:
On Mon, Oct 29, 2012 at 12:52 PM, Kevin Fenzi kevin@scrye.com wrote:
This plan has also come up before. ;)
I didn't realize this had been brought up before. Do you have a link to the discussion? I've browsed through the EPEL archives and I didn't see something like this.
Not off hand. I know it was suggested in the past tho. ;)
On Mon, Oct 29, 2012 at 12:52 PM, Kevin Fenzi kevin@scrye.com wrote:>
- We never know when exactly a point release is going to appear
until it does. RH never announces them in advance. So, might lead to scrambling. It's pretty unlikely we could push those updates the same day as the point release... so when would we? would they go through testing as usual?
We could publish a policy that the "EPEL flag day" is two weeks after the day that RHEL ships a point release.
Pros:
A maintainer can push an "incompatible update" into epel-testing on the day that RHEL ships, and then have their package hit epel-stable two weeks later on the agreed-upon flag day. (Of course, if a maintainer wanted to get their update into updates-testing sooner, that's fine too.)
Easy to remember: "two weeks" is the same time as Bodhi testing.
CentOS and SL are important, but we can't really affect the release schedules for these projects, so it's yet another one-way street. I think we have to just make a best effort. A consistent two week gap would these projects some leeway while not compromising on consistency.
Cons:
- We would need some coordination to ensure that the signing process happens on the day of RHEL's point release, and two weeks afterward. I'm not involved with the sigining task... hopefully this is not a huge deal?
Not a big deal. I sign and push updates almost every day.
- Technically we would have two release days (RHEL + EPEL) instead of one (RHEL).
Right.
- Once we push those incompatible ones that require the new point release, does that just leave people who are on an older one out
in the cold? Or they get the updates and it breaks them even though they didn't apply the point release?
I'm having trouble picturing a scenario where this problem could happen in RHEL+EPEL. Can you explain more? (I'm not envisioning that these new packages would have dependencies on the redhat-release package version number; only that we would try to hit the dates on the calendar.)
So, say RHEL 6.4 comes out. We set our EPEL6 'incompatible upgrade day' as 2 weeks after that.
Some people upgrade to 6.4 immediately. Should be ok, as our upgrades haven't happened yet.
Some people wait and stay on 6.x.
2 weeks pass. EPEL incompatible upgrade day arrives, we push updates out.
People who upgraded to 6.4 already see a bunch of updates that are incompatible and are annoyed since they already did their point release.
People on say 6.1 who never applied the point release see a bunch of updates out of the blue. Perhaps some of these EPEL updates require newer packages or new packages in 6.4 only, so they just see broken updates. Granted we have never catered to those folks on old releases much...
Anyhow, I guess the big problem I see is that some people will upgrade before our 2 weeks and then have to go through 2 'major' upgrades in a row.
kevin
epel-devel@lists.fedoraproject.org