Upgrade of unmaintained packages

Mike A. Harris mharris at redhat.com
Sun Feb 1 09:34:47 UTC 2004


On Fri, 30 Jan 2004, Aurelien Bompard wrote:

>I have a question about distribution upgrade : how should we deal with
>unmaintained packages which don't work in the new distribution ? Let's say
>we have included a program in Extras (or main) and the project stops for
>some reason. At some point in the future, the program will stop working
>(API change, glibc upgrade, ...). How should we deal with such a package
>(except not including it in the first place of course ;) ) ?
>We could tell Anaconda to remove it (well I don't know much about Anaconda,
>but I suppose it is possible), but what about online upgrades using yum or
>apt ?

If the package becomes unmaintained, as in "unmaintained rpm 
package that used to be maintained in the Fedora Project", then 
it makes the most sense to do what has been done for years in the 
OS itself.

For a package which has had it's functionality replaced by 
another, sometimes we use Obsoletes in the new package.  An 
example where that is good, is where 2 packages provide similar 
functionality, but you wouldn't want or need both installed at 
the same time.  console-tools vs. kbd for example.

For a package which has had it's functionality replaced by a new 
package but which someone might want to use the old one still, we 
should do absolutely nothing at all.  An example of this would be 
"UW imap".  We now have cyrus-imapd and dovecot imap servers.  
All 3 servers should easily co-exist should one desire to do so, 
and it's possible that one might want to leave UW imap installed 
and keep using it on an upgrade.  For example, if someone uses UW 
imap and upgrades, they don't want some new imap server 
obsoleting their old one and uninstalling it, and then not 
allowing them to install the old one again.  That would be very 
wrong and would upset people very badly.  Don't do that.

Even if we KNEW that the old package would break because of 
something, it is not right to Obsolete or remove it.  Someone 
might fix it and recompile it, and be unable to update the new 
package.

Trying to be too smart has concequences of the form of upset 
users.  There is no perfect solution all around to the problem 
you propose.  I think the solution we have used all along for 
years in the OS works good enough.


-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat





More information about the devel mailing list