"newer packages"

[Toshio Kuratomi]

On 09/08/2009 10:51 AM, Ray Van Dolson wrote:
> On Tue, Sep 08, 2009 at 12:28:35PM -0500, Mike McGrath wrote:
>> Should we have a stronger effort to replace older RHEL packages if we
>> put them in their own namespace and don't conflict?
>>
>> This is sort of a nuanced problem since RHEL5 doesn't feel nearly as
>> old as RHEL4 did at this point in it's release cycle.  But still,
>> people do want newer versions of these packages.
> 
> I'd be in favor of something like this... would the separate namespace
> by enough separation, or should there be an actual additional repo for
> packages like this?
> 
> Prior would obviously be simpler.
> 
> Something like this for mutt (mutt15 perhaps) would be great.
> 
We'd need to decide whether we'd be okay with Conflicts.

In Fedora repositories, we're trying to eliminate use of Conflicts.  If
we want to package a mutt15 package in Fedora, we rename the package,
change binary locations, change directory locations, update the conf
files and init scripts to use the new directories, and possibly patch
source to find the new directories.  Doing all this work is generally
okay since there's very few packages that we'd want to parallel install
older and newer versions in Fedora.  Fedora is updating to the latest
versions at a rapid pace and the older releases of Fedora are EOL'd
before people would want to parallel install both packages.  In
RHEL/Centos, there's a larger window between releases and a larger
window of a release being supported.

Using Conflicts we'd rename the package but install to the same
directories as the current postgresql.  The system admin would have to
choose whether to install postgresql-* from RHEL or postgresql8.3 from
the EPEL repository... they couldn't have both.

We'd also need to think about how we want to deal with package sets that
depend on each other.  For instance, if we build postgresql8.4 packages
so people can stick with the postgres db that came with RHEL or use a
newer version, we will need to:

1) Decide whether optional newer dependencies by the newer postgresql
should be kept or we should make it more drop in (in the postgres I've
built for Infrastructure, I chose not to upgrade to a newer tcl or build
optional profiling packages that the current Fedora postgresql needs)

2) Decide whether to build other packages against the newer postgresql
(I have built a postgresql8.3-pgpool-II package that targets my
postgresql8.3, for instance).

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20090908/c2ae0351/attachment.sig>