Ok there are a class of packages we are running into which I would consider dead-end packages. The upstream usually makes changes between major releases which make former releases non-functional without some work (or in some cases LOTs of work). I think we should look at these packages as not falling under standard packaging as it becomes a pain in the ass to deal with on an enterprise packaging standpoint.
Pulling up something I brought up a long time ago, I would like us to figure out ways to deal with this.] As Bernard Johnson pointed out we need to work on a naming convention for these applications to deal with the fact that well, people rely on them, and their update policy is a lot of the time crap.
So taking Bernards and some stuff we talked about a year or two back.. lets see if we can do the following:
1) Declare a package will need to follow 'Bad-EOL' policy (whatever that is finally decided) 2) Change the naming of the current package from <package>-x.y.z to <package>xy-x.y.z with appropriate tags (obsolete? replaces with predjudice?) to replace the package. 3) If EOL of old package add a standard file in the package outlining that EPEL is EOL this package and will not do updates without community help to do so. Also outlining that upgrading to newer versions of the package is not simple and you should follow steps at "Fill in page here if it exists." 3) Make packages in newer versions also match this name: <package>(x+1).y.z-(x+1).y.z and keep that up to date until its no longer possible. 4) Goto #2 when needed.
- Declare a package will need to follow 'Bad-EOL' policy (whatever
that is finally decided) 2) Change the naming of the current package from <package>-x.y.z to <package>xy-x.y.z with appropriate tags (obsolete? replaces with predjudice?) to replace the package. 3) If EOL of old package add a standard file in the package outlining that EPEL is EOL this package and will not do updates without community help to do so. Also outlining that upgrading to newer versions of the package is not simple and you should follow steps at "Fill in page here if it exists." 3) Make packages in newer versions also match this name: <package>(x+1).y.z-(x+1).y.z and keep that up to date until its no longer possible. 4) Goto #2 when needed.
Why try to solve this problem only in EPEL? It exists in the main Fedora space as well. Packages like Wordpress, Mediawiki, any Rails application, java stuff, etc are all like this. I've often thought there's got to be a better way. Should we get this in front of the package committee? I see these with two major issues. 1. Upgrading causes breakage or at least manual intervention 2. Making these package FHS compliant is a real PITA and then often makes it so upstream can't/won't help due to your installation method (paths etc).
I'd rather see this handled by the Package people and if we need specific discussion for EPEL, we can have it.
Thoughts? stahnma
On Feb 1, 2010, at 5:25 PM, Michael Stahnke wrote:
Why try to solve this problem only in EPEL? It exists in the main Fedora space as well. Packages like Wordpress, Mediawiki, any Rails application, java stuff, etc are all like this. I've often thought there's got to be a better way. Should we get this in front of the package committee? I see these with two major issues.
- Upgrading causes breakage or at least manual intervention
- Making these package FHS compliant is a real PITA and then often
makes it so upstream can't/won't help due to your installation method (paths etc).
I'd rather see this handled by the Package people and if we need specific discussion for EPEL, we can have it.
I agree, I don't think this is just an EPEL thing, however the restrictions on non-compatible upgrades are much more stringent with EPEL than Fedora. Of course in this case we are talking more specifically about packages that have no upgrade path, or a difficult one.. rather than just a non-compatible upgrade.
I think this discussion also overlaps with others that have occurred regarding simply the ability to introduce newer versions of software that people want, which is more appropriately from the 'new install' perspective rather than the 'upgrade' perspective. That said, Fedora is introducing 'python3' parallel install in F13 which breaks the barrier for multiple packages of differing versions. With Moin as an example, even if moin-1.5 was still maintainable... there is no way that I would use it for a new install via EPEL, forcing me to rebuild from Fedora packages and maintain my own set. Where as if we were able to introduce moin18, or I guess moin19 now.. new installs would be peachy, and old users of moin-1.5 would not be affected.
This is pretty much exactly on the path of what The IUS Community Project [1] does with packages, but in a different context where IUS packages replace stock RHEL packages. From a packaging standpoint, there isn't much difference. The process [2] is rather simple, and after nearly 6 months since IUS launched there have been limited obstacles [3]. The basics are doing something like this (with moin19 for an example):
# before the preamble %define basever 1.9 %define real_name moin %define name moin19
# after preamble Provides: %{real_name} = %{version}-%{release} Conflicts: %{real_name} < %{basever}
# and for all sub packages Provides: %{real_name}-subpackage = %{version}-%{release} Conflicts: %{real_name}-subpackage < %{basever}
This is the IUS model, where replacement packages conflict and replace the existing package (not side-by-side except for Python). If you are looking to enable side-by-side parallel installs of the original package, and the replacement (i.e. moin19) you are talking about a lot of extra work, which in my opinion isn't usually worth it considering most people [I would imagine] wouldn't want/need/care about running both side-by-side.
References:
[1] http://iuscommunity.org [2] http://wiki.iuscommunity.org/Doc/DeveloperGuide#Converting_Existing_Packages... [3] https://bugzilla.redhat.com/show_bug.cgi?id=529719
--- derks
On Mon, Feb 01, 2010 at 05:25:53PM -0600, Michael Stahnke wrote:
- Declare a package will need to follow 'Bad-EOL' policy (whatever
that is finally decided) 2) Change the naming of the current package from <package>-x.y.z to <package>xy-x.y.z with appropriate tags (obsolete? replaces with predjudice?) to replace the package. 3) If EOL of old package add a standard file in the package outlining that EPEL is EOL this package and will not do updates without community help to do so. Also outlining that upgrading to newer versions of the package is not simple and you should follow steps at "Fill in page here if it exists." 3) Make packages in newer versions also match this name: <package>(x+1).y.z-(x+1).y.z and keep that up to date until its no longer possible. 4) Goto #2 when needed.
Why try to solve this problem only in EPEL? It exists in the main Fedora space as well. Packages like Wordpress, Mediawiki, any Rails application, java stuff, etc are all like this. I've often thought there's got to be a better way. Should we get this in front of the package committee? I see these with two major issues.
- Upgrading causes breakage or at least manual intervention
For this one, note that Fedora moves fast enough that it isn't the same kind of issue as for EPEL.
ie: Fedora 11 packages moin-1.5 Fedora 12 packages moin-1.6
We do break compatibility on the release boundary and users do have to perform manual upgrades there. After 13 months, Fedora 11 is no longer supported and we don't have to worry about security issues or bugfixes to moin-1.5 anymore. With EPEL, this is not the case -- you either have to backport security fixes or perform an incompatible update within the RHEl-5 timeframe.
- Making these package FHS compliant is a real PITA and then often
makes it so upstream can't/won't help due to your installation method (paths etc).
This is a problem that won't be solved by ignoring the FHS. Do you have another idea of how to do it?
-Toshio
Why try to solve this problem only in EPEL? It exists in the main Fedora space as well. Packages like Wordpress, Mediawiki, any Rails application, java stuff, etc are all like this. I've often thought there's got to be a better way. Should we get this in front of the package committee? I see these with two major issues.
- Upgrading causes breakage or at least manual intervention
For this one, note that Fedora moves fast enough that it isn't the same kind of issue as for EPEL.
ie: Fedora 11 packages moin-1.5 Fedora 12 packages moin-1.6
We do break compatibility on the release boundary and users do have to perform manual upgrades there. After 13 months, Fedora 11 is no longer supported and we don't have to worry about security issues or bugfixes to moin-1.5 anymore. With EPEL, this is not the case -- you either have to backport security fixes or perform an incompatible update within the RHEl-5 timeframe.
I don't think the time frame is the only issue. It can and probably has happened in Fedora upgrades as well. I can't think of a good example off the top of my head, but I know I've had issues in the past with some packages in the time frame of a supported Fedora version. (it was probably mediawiki). If Fedora doesn't want to have a policy, or feels it doesn't need one, that's fine. I was just hoping to get it solved upsteam before we sat down and tried to invent our own rules.
- Making these package FHS compliant is a real PITA and then often
makes it so upstream can't/won't help due to your installation method (paths etc).
This is a problem that won't be solved by ignoring the FHS. Do you have another idea of how to do it?
For this problem, unless we start spewing junk in /srv or something, then no, I have no real answers for this one. But rails specifically expects applications to be containerized, and doesn't want configurations in /etc and variable data in var etc. I assume java is much the same way with their jar/war/ear files, but I try not to touch the stuff :) I think other web applications are normally like that too.
On Mon, Feb 01, 2010 at 07:22:35PM -0500, Toshio Kuratomi wrote:
For this one, note that Fedora moves fast enough that it isn't the same kind of issue as for EPEL.
We do break compatibility on the release boundary and users do have to perform manual upgrades there. After 13 months, Fedora 11 is no longer supported and we don't have to worry about security issues or bugfixes to moin-1.5 anymore.
Nevertheless those issues happen in fedora. This is especially true for development related packages. There are a lot of automake/autoconf versions in parallel in fedora. Also sometime it is very handy to have parallel versions of libraries with incompatible API but still used previous API (for example I maintained libnet and libnet10). Also at some time gfortran was buggy (though it was already the main compiler) but it was nice to have a package (cernlib) compiled with g77 or gfortran such that users may choose the one they prefer. The possibility to push preview packages in fedora is also something interesting, and there is also the issues of transitions (like the python3 issue).
In the end tackling the issue of installing packages in parallel in a global and comprehensive way instead of ditching the issue because it smells like long time support in fedora would be, in my opinion, beneficial -- especially because this is not an easy isue. However, my opinion is also that there is too much 'political' pressure against working on this subject in fedora, so EPEL may be a better place to discuss and set up policies that could then be reused in fedora when opposition anything that could be useful for long time support becomes less strong.
-- Pat
On Mon, Feb 1, 2010 at 4:25 PM, Michael Stahnke mastahnke@gmail.com wrote:
- Declare a package will need to follow 'Bad-EOL' policy (whatever
that is finally decided) 2) Change the naming of the current package from <package>-x.y.z to <package>xy-x.y.z with appropriate tags (obsolete? replaces with predjudice?) to replace the package. 3) If EOL of old package add a standard file in the package outlining that EPEL is EOL this package and will not do updates without community help to do so. Also outlining that upgrading to newer versions of the package is not simple and you should follow steps at "Fill in page here if it exists." 3) Make packages in newer versions also match this name: <package>(x+1).y.z-(x+1).y.z and keep that up to date until its no longer possible. 4) Goto #2 when needed.
Why try to solve this problem only in EPEL? It exists in the main Fedora space as well. Packages like Wordpress, Mediawiki, any Rails application, java stuff, etc are all like this. I've often thought there's got to be a better way. Should we get this in front of the package committee? I see these with two major issues.
- Upgrading causes breakage or at least manual intervention
- Making these package FHS compliant is a real PITA and then often
makes it so upstream can't/won't help due to your installation method (paths etc).
I believe it was brought up sometime ago in the murky passed packaging and was listed as "Need someone to experiment with it first before we make it for everyone." I could of course be completely pulling things out of the ether on it... but that was why I had left it in limbo 2 years ago.. I didn't have the time/etc to do it locally. I have better aim on time for this now.
If we can show it can be done, and how its done, its easier to get it standardized knowing of course that our implementation will have to be altered as corner cases come up.
I'd rather see this handled by the Package people and if we need specific discussion for EPEL, we can have it.
Thoughts? stahnma
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Mon, 1 Feb 2010 13:51:17 -0700 Stephen John Smoogen smooge@gmail.com wrote:
Ok there are a class of packages we are running into which I would consider dead-end packages. The upstream usually makes changes between major releases which make former releases non-functional without some work (or in some cases LOTs of work). I think we should look at these packages as not falling under standard packaging as it becomes a pain in the ass to deal with on an enterprise packaging standpoint.
Pulling up something I brought up a long time ago, I would like us to figure out ways to deal with this.] As Bernard Johnson pointed out we need to work on a naming convention for these applications to deal with the fact that well, people rely on them, and their update policy is a lot of the time crap.
So taking Bernards and some stuff we talked about a year or two back.. lets see if we can do the following:
...snip...
I have been pondering on this as well, and I wonder if another better approach might be:
- Add another repo called "slipstream" or "bleeding" or "incompatibeupdates" or some other catchy name.
- Make new versions for the packages that fall into this issue in that repo. ie, mediawiki, rdiff-backup, moin, nagios-3, etc.
- For the case of packages where the old version works and still is supported, let it stay in the normal epel/testing repo in addition. For things that are not supported/broken/have known security issues, remove them from the epel/testing repo.
- Push updates to the bleeding repo as needed. The expectation for that repo would be: We will try and avoid incompatible upgrades, but that may be impossible, so you should watch every update from this repo and test it in your env. Packages in the bleeding repo may well be newer than ones in the stable repo. You should EITHER use the stable repo only, or the bleeding+stable.
I know another repo will be a big pain, but I think this would help us communicate to our users when something is a web app that is not really stable at all and updates rapidly and incompatibly. I think another repo (disabled by default) would communicate this better than 'nagios3' or 'mediawiki-foo' in the "stable" repo.
Thoughts?
kevin
On 02/06/2010 10:29 PM, Kevin Fenzi wrote:
On Mon, 1 Feb 2010 13:51:17 -0700 Stephen John Smoogen smooge@gmail.com wrote:
Ok there are a class of packages we are running into which I would consider dead-end packages. The upstream usually makes changes between major releases which make former releases non-functional without some work (or in some cases LOTs of work). I think we should look at these packages as not falling under standard packaging as it becomes a pain in the ass to deal with on an enterprise packaging standpoint.
Pulling up something I brought up a long time ago, I would like us to figure out ways to deal with this.] As Bernard Johnson pointed out we need to work on a naming convention for these applications to deal with the fact that well, people rely on them, and their update policy is a lot of the time crap.
So taking Bernards and some stuff we talked about a year or two back.. lets see if we can do the following:
...snip...
I have been pondering on this as well, and I wonder if another better approach might be:
Add another repo called "slipstream" or "bleeding" or "incompatibeupdates" or some other catchy name.
Make new versions for the packages that fall into this issue in that repo. ie, mediawiki, rdiff-backup, moin, nagios-3, etc.
For the case of packages where the old version works and still is supported, let it stay in the normal epel/testing repo in addition. For things that are not supported/broken/have known security issues, remove them from the epel/testing repo.
Push updates to the bleeding repo as needed. The expectation for that repo would be: We will try and avoid incompatible upgrades, but that may be impossible, so you should watch every update from this repo and test it in your env. Packages in the bleeding repo may well be newer than ones in the stable repo. You should EITHER use the stable repo only, or the bleeding+stable.
I know another repo will be a big pain, but I think this would help us communicate to our users when something is a web app that is not really stable at all and updates rapidly and incompatibly. I think another repo (disabled by default) would communicate this better than 'nagios3' or 'mediawiki-foo' in the "stable" repo.
100% agree with you. But I am very much afraid that we do not have the resources.
On Sat, Feb 6, 2010 at 1:29 PM, Kevin Fenzi kevin@scrye.com wrote:
On Mon, 1 Feb 2010 13:51:17 -0700 Stephen John Smoogen smooge@gmail.com wrote:
Ok there are a class of packages we are running into which I would consider dead-end packages. The upstream usually makes changes between major releases which make former releases non-functional without some work (or in some cases LOTs of work). I think we should look at these packages as not falling under standard packaging as it becomes a pain in the ass to deal with on an enterprise packaging standpoint.
Pulling up something I brought up a long time ago, I would like us to figure out ways to deal with this.] As Bernard Johnson pointed out we need to work on a naming convention for these applications to deal with the fact that well, people rely on them, and their update policy is a lot of the time crap.
So taking Bernards and some stuff we talked about a year or two back.. lets see if we can do the following:
...snip...
I have been pondering on this as well, and I wonder if another better approach might be:
- Add another repo called "slipstream" or "bleeding" or
"incompatibeupdates" or some other catchy name.
- Make new versions for the packages that fall into this issue in that
repo. ie, mediawiki, rdiff-backup, moin, nagios-3, etc.
- For the case of packages where the old version works and still is
supported, let it stay in the normal epel/testing repo in addition. For things that are not supported/broken/have known security issues, remove them from the epel/testing repo.
- Push updates to the bleeding repo as needed. The expectation for that
repo would be: We will try and avoid incompatible upgrades, but that may be impossible, so you should watch every update from this repo and test it in your env. Packages in the bleeding repo may well be newer than ones in the stable repo. You should EITHER use the stable repo only, or the bleeding+stable.
I know another repo will be a big pain, but I think this would help us communicate to our users when something is a web app that is not really stable at all and updates rapidly and incompatibly. I think another repo (disabled by default) would communicate this better than 'nagios3' or 'mediawiki-foo' in the "stable" repo.
Thoughts?
I think it has a nugget to work on so I am not against this.. What goes into stable? I can see slipstream getting all the packages because its easier to break things.. but I don't see much reason to put stuff into stable.
kevin
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Mon, 8 Feb 2010 16:26:18 -0700 Stephen John Smoogen smooge@gmail.com wrote:
I think it has a nugget to work on so I am not against this.. What goes into stable? I can see slipstream getting all the packages because its easier to break things.. but I don't see much reason to put stuff into stable.
Well, we would need to be strict I think for what can go into the slipstream repo, and also it should be disabled by default in epel-release, so only those that enable it would see those packages.
I would think maintainers would like to have their packages in testing/stable to reach the widest audience, and only use slipstream if there was no other choice.
I agree it would be more work to have another repo, possibly more than we have people to work on at this point, but I think thats the best solution if we can pull it off.
kevin
On Thu, Feb 11, 2010 at 1:36 PM, Kevin Fenzi kevin@tummy.com wrote:
On Mon, 8 Feb 2010 16:26:18 -0700 Stephen John Smoogen smooge@gmail.com wrote:
I think it has a nugget to work on so I am not against this.. What goes into stable? I can see slipstream getting all the packages because its easier to break things.. but I don't see much reason to put stuff into stable.
Well, we would need to be strict I think for what can go into the slipstream repo, and also it should be disabled by default in epel-release, so only those that enable it would see those packages.
I would think maintainers would like to have their packages in testing/stable to reach the widest audience, and only use slipstream if there was no other choice.
I agree it would be more work to have another repo, possibly more than we have people to work on at this point, but I think thats the best solution if we can pull it off.
Ok here is my crazy ass idea that probably not possible but an idea
EPEL Slipstream (4,5,6) -> Fedora Rawhide EPEL Testing -> Fedora Branch for testing EPEL Stable -> Fedora Release EPEL Updates -> Fedora Release Updates
Stable branched out of Slipstream every RHEL beta time into EPEL-testing Stuff is 'tested/branched' into Stable at RHEL release time Updates that meet requirements go into epel-updates. An EPEL-X.Y branch is kept for 2 RHEL minor releases (X.Y) or 18 months.
so we would 'branch' to EPEL-5.5 and (sometime soon EPEL-4.9? ) stuff is 'tested' (optimistically) and put into EPEL-5.5 stable when RHEL-5.5 stable is done. Updates to packages are pushed into EPEL-updates 5.5 and after 5.7 comes out is 'archived' off to someplace.
and yes this would be a big amount of infrastructure changes that people would need to help with. (so probably not too workable).
epel-devel@lists.fedoraproject.org