FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 05-11-2010, 10:30 PM
BJ Dierkes
 
Default Supporting Multiple Package Versions (pkg, pkgXY, pkgXZ)

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




_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-11-2010, 10:44 PM
Rahul Sundaram
 
Default Supporting Multiple Package Versions (pkg, pkgXY, pkgXZ)

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-11-2010, 11:48 PM
Stephen John Smoogen
 
Default Supporting Multiple Package Versions (pkg, pkgXY, pkgXZ)

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.


--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-12-2010, 12:12 AM
Rahul Sundaram
 
Default Supporting Multiple Package Versions (pkg, pkgXY, pkgXZ)

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-12-2010, 12:32 AM
BJ Dierkes
 
Default Supporting Multiple Package Versions (pkg, pkgXY, pkgXZ)

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


_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-12-2010, 03:10 AM
Toshio Kuratomi
 
Default Supporting Multiple Package Versions (pkg, pkgXY, pkgXZ)

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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 05-12-2010, 04:27 AM
Kevin Fenzi
 
Default Supporting Multiple Package Versions (pkg, pkgXY, pkgXZ)

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

Thread Tools




All times are GMT. The time now is 03:26 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org