>
> 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.
>
>
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

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

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.
> 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.

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_For_IU S
[3] https://bugzilla.redhat.com/show_bug.cgi?id=529719

---
derks


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

On Mon, Feb 01, 2010 at 05:25:53PM -0600, Michael Stahnke wrote:
> >
> > 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.
> >
> >
> 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

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.

> 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).
>
This is a problem that won't be solved by ignoring the FHS. Do you have
another idea of how to do it?

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

>> 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
>
> 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.


>
>> 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).
>>
> 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.

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

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

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

On Mon, Feb 1, 2010 at 4:25 PM, Michael Stahnke <mastahnke@gmail.com> wrote:
>>
>> 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.
>>
>>
> 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 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
>



--
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning

_______________________________________________
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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list

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.


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

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
>
>



--
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning

_______________________________________________
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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list