Hello all,
Lately there have been a number of package additions/requests to Fedora/EPEL that introduce new versions of a package, whilst allowing the original package to remain in-tact. Some examples:
python26 - https://bugzilla.redhat.com/show_bug.cgi?id=573151 python3 - https://bugzilla.redhat.com/show_bug.cgi?id=554799 sqlite36 - https://bugzilla.redhat.com/show_bug.cgi?id=571458
These examples are all parallel installable. Python has a separate 'site_packages' directory based on major branch version (stock = 2.4, python26 = 2.6, python3 = 3.1). SQLite has a unique binary path (stock = /usr/bin/sqlite3, sqlite36 = /usr/bin/sqlite36). That said, RedHat has also begun introducing newer versions of packages that conflict/replace with their previous counterparts.
Example: postgres84
Conflicts: postgresql < 8.4 Provides: postgresql = %{version}-%{release}
Granted, postgresql84 is likely a one-off for Redhat because they and Fedora Infrastructure use PgSQL. However on this same note, the IUS Community Project [1] has the same exact process for 'replacing' RHEL packages with updated counterparts (i.e. php replaced by php52, php53, etc). Being the primary maintainer of IUS, my question has to do with the fact that IUS relies on EPEL and is meant to compliment both RHEL and EPEL with optional upgrades for packages that are locked (incompatible upgrade paths) on a branch and can't update. The last thing I want is to maintain a package in IUS, that would be accepted and benefit EPEL. Seeing as RHEL allows the practice of Conflict/Replace ... is this a policy that EPEL would also embrace? Or is it something we want to strictly avoid as, with anything, it has the potential to complicate things.
It was my understanding previously that these types of packages would be rejected because they 'Conflict with stock RHEL base channel packages'. However I think the policy of not conflicting doesn't really apply if a user wants the conflicting package and explicitly has to remove the stock package and install a comparable package that 'provides' it (postgresql84 Provides: postgresql).
References:
[1] http://iuscommunity.org, http://dl.iuscommunity.org/pub/ius
--- derks
On 05/12/2010 04:00 AM, BJ Dierkes wrote:
Granted, postgresql84 is likely a one-off for Redhat because they and Fedora Infrastructure use PgSQL. However on this same note, the IUS Community Project [1] has the same exact process for 'replacing' RHEL packages with updated counterparts (i.e. php replaced by php52, php53, etc). Being the primary maintainer of IUS, my question has to do with the fact that IUS relies on EPEL and is meant to compliment both RHEL and EPEL with optional upgrades for packages that are locked (incompatible upgrade paths) on a branch and can't update. The last thing I want is to maintain a package in IUS, that would be accepted and benefit EPEL. Seeing as RHEL allows the practice of Conflict/Replace ... is this a policy that EPEL would also embrace? Or is it something we want to strictly avoid as, with anything, it has the potential to complicate things.
IMO, I think it is time for EPEL to merge with IUS. We should strive to create parallel installable packages as much as possible but if there is a explicit package conflict and NOT a silent obsolete, then it should be allowed. I would avoid integrating apps that build on such conflict infrastructure packages however.
Rahul
On Tue, May 11, 2010 at 4:44 PM, Rahul Sundaram metherid@gmail.com wrote:
On 05/12/2010 04:00 AM, BJ Dierkes wrote:
Granted, postgresql84 is likely a one-off for Redhat because they and Fedora Infrastructure use PgSQL. However on this same note, the IUS Community Project [1] has the same exact process for 'replacing' RHEL packages with updated counterparts (i.e. php replaced by php52, php53, etc). Being the primary maintainer of IUS, my question has to do with the fact that IUS relies on EPEL and is meant to compliment both RHEL and EPEL with optional upgrades for packages that are locked (incompatible upgrade paths) on a branch and can't update. The last thing I want is to maintain a package in IUS, that would be accepted and benefit EPEL. Seeing as RHEL allows the practice of Conflict/Replace ... is this a policy that EPEL would also embrace? Or is it something we want to strictly avoid as, with anything, it has the potential to complicate things.
IMO, I think it is time for EPEL to merge with IUS. We should strive to create parallel installable packages as much as possible but if there is a explicit package conflict and NOT a silent obsolete, then it should be allowed. I would avoid integrating apps that build on such conflict infrastructure packages however.
Ok having dealt with several ugly packages.. I have to agree that parallel installed packages is the way to go for most webapps. The issues I see will be dealing with getting them through the Fedora packaging reviews AND their Fedora upstream maintainers. Both who have an interest in not having this happen as it duplicates work and makes their lives hard in some ways.
I am not 'against' this proposal, I just think we will need to flesh out a lot more on this and need to get input from various places on how to better do this.
On 05/12/2010 05:18 AM, Stephen John Smoogen wrote:
Ok having dealt with several ugly packages.. I have to agree that parallel installed packages is the way to go for most webapps. The issues I see will be dealing with getting them through the Fedora packaging reviews AND their Fedora upstream maintainers. Both who have an interest in not having this happen as it duplicates work and makes their lives hard in some ways.
I am not 'against' this proposal, I just think we will need to flesh out a lot more on this and need to get input from various places on how to better do this.
A few more thoughts on why I think a merge is appropriate. Fedora has traditionally been focussed on a single runtime for various things. The latest Python, latest PHP and so on but while this was somewhat appropriate for a fast moving distribution, it has become increasingly evident that we cannot sustain that focus and have to introduce parallel installable versions. Python is certainly moving towards that path with Python 3 in Fedora and Python maintainer has already indicated he would be willing to do Python27 and more in Fedora and EPEL as and when needed. Ruby SIG has similar plans as well. That's the case for Fedora which influences EPEL directions as well. On the other hand, what Red Hat does with the base repo can and should influence EPEL directions as well. We now have a precedent with Postgres and it is clear that customers are demanding it with the growing gap between EL releases. Within EPEL, there is a even higher need for similar flexibility because we have a larger package set. As long as the conflicts are managed on a case by case with a focus on infrastructure packages, I believe we should accommodate such interests because it provides better value and EPEL users (and Red Hat customers) are doing it on their own anyway. By merging the infrastructure and enforcing a review process, we will bring into fold and provide higher quality for what would exist otherwise in perhaps a more loosely defined way.
Rahul
On May 11, 2010, at 6:48 PM, Stephen John Smoogen wrote:
Ok having dealt with several ugly packages.. I have to agree that parallel installed packages is the way to go for most webapps. The issues I see will be dealing with getting them through the Fedora packaging reviews AND their Fedora upstream maintainers. Both who have an interest in not having this happen as it duplicates work and makes their lives hard in some ways.
I am not 'against' this proposal, I just think we will need to flesh out a lot more on this and need to get input from various places on how to better do this.
I completely agree. I think what we [EPEL] need to solve is how we can provide:
A) Extra packages that RHEL doesn't provide B) Stability in those packages, shadowing RHEL (life cycle, not introducing breakage, etc) C) Giving the users what they want (i.e. latest versions of those packages)
B and C inherently conflict with each other because you can't offer the latest versions (or even latest branches) of software without introducing breakage or the potential of. We keep EPEL packages in line with the latest stable version as long as possible until an incompatible version is released or the source version branches, and then that package becomes obsolete as soon as new users start considering it 'too old'. If EPEL can branch packages along with upstream source branches, C (i.e. pkgXY) has the potential to solve B and C.
nginx is a perfect example. I've received multiple requests for the latest stable version of nginx-0.7 via IUS because the EPEL version of 0.6.x is too old [for them]. Existing users (B) need nginx-0.6 to remain as-is until they plan a maintenance where they can methodically, and intentionally make the jump to say nginx07-0.7.x (knowing there may be potential upgrade issues), where-as new users of EPEL/nginx (C) want nginx07-0.7.x to start with and would rather do a source install (or go somewhere else like IUS) to get a more recent version. True 0.6.x is still maintainable, but it's not what new user's of nginx want (same for a lot of RHEL packages).
Any how, none of this is new... I'm simply re-iterating.
--- derks
On Tue, May 11, 2010 at 05:48:25PM -0600, Stephen John Smoogen wrote:
On Tue, May 11, 2010 at 4:44 PM, Rahul Sundaram metherid@gmail.com wrote:
On 05/12/2010 04:00 AM, BJ Dierkes wrote:
Granted, postgresql84 is likely a one-off for Redhat because they and Fedora Infrastructure use PgSQL. However on this same note, the IUS Community Project [1] has the same exact process for 'replacing' RHEL packages with updated counterparts (i.e. php replaced by php52, php53, etc). Being the primary maintainer of IUS, my question has to do with the fact that IUS relies on EPEL and is meant to compliment both RHEL and EPEL with optional upgrades for packages that are locked (incompatible upgrade paths) on a branch and can't update. The last thing I want is to maintain a package in IUS, that would be accepted and benefit EPEL. Seeing as RHEL allows the practice of Conflict/Replace ... is this a policy that EPEL would also embrace? Or is it something we want to strictly avoid as, with anything, it has the potential to complicate things.
IMO, I think it is time for EPEL to merge with IUS. We should strive to create parallel installable packages as much as possible but if there is a explicit package conflict and NOT a silent obsolete, then it should be allowed. I would avoid integrating apps that build on such conflict infrastructure packages however.
Ok having dealt with several ugly packages.. I have to agree that parallel installed packages is the way to go for most webapps. The issues I see will be dealing with getting them through the Fedora packaging reviews AND their Fedora upstream maintainers. Both who have an interest in not having this happen as it duplicates work and makes their lives hard in some ways.
Note that Fedora Guidelines would not pass Conflict and Replace style packages (such as postgresql8.4 apparently does) at the moment. However, either that could be changed with a suitable draft and enough thought behind it or EPEL could allow it where Fedora does not.
https://fedoraproject.org/wiki/Packaging:Conflicts
-Toshio
On Tue, 11 May 2010 17:30:46 -0500 BJ Dierkes wdierkes@5dollarwhitebox.org wrote:
...snip...
It was my understanding previously that these types of packages would be rejected because they 'Conflict with stock RHEL base channel packages'. However I think the policy of not conflicting doesn't really apply if a user wants the conflicting package and explicitly has to remove the stock package and install a comparable package that 'provides' it (postgresql84 Provides: postgresql).
Well, they are not currently something we accept.
One thing to keep in mind is that Conflicts are nasty to the end user. You select things and it downloads it and shows you it's going to install it and then... wham. Conflict. Sorry, can't do this. This can be quite anoying if you choose things at install time or have a ks that happens to pull in conflicting packages. If you conflict you have to make a system wide decision to use just that newer version, which also kinda sucks.
My personal feeling is that we should continue to avoid conflicts in these packages and require that they be parallel installable with the base provided version.
kevin
epel-devel@lists.fedoraproject.org
-
BJ Dierkes -
Kevin Fenzi -
Rahul Sundaram -
Stephen John Smoogen -
Toshio Kuratomi