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