Upgrade of unmaintained packages

Joseph Fannin jhf at rivenstone.net
Fri Jan 30 21:19:47 UTC 2004


On Fri, Jan 30, 2004 at 05:56:31PM +0200, Panu Matilainen wrote:
> On Fri, 2004-01-30 at 17:43, Aurelien Bompard wrote:
> > Hi all,
> > 
> > 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 ?
> 
> Anaconda, up2date and yum never remove packages unless they are
> explicitly obsoleted by something else, AFAIK. (well, anaconda has some
> special remove-this-crap blacklist items like linuxconf :) Apt on the
> other hand does remove packages for which dependencies can no longer be
> satisfied (and occasionally gets itself and you into trouble just
> because of that :)
> 

    Apt only does this is you ask for this behavior -- this is the
difference between upgrade and dist-upgrade.  Apt also asks whether
removing packages is okay before proceding.

    The last I knew (and it's been a while), Anaconda was basically
using rpm --force to ensure that all packages get upgraded.  If this
is the only "supported" upgrade method, I think it'll be hard to count
on the packages in Fedora Core having the strict version dependencies
that make the apt-style plain 'upgrade' possible.  Debian ends up
fixing a lot of package dependencies after the fact (i.e. it breaks
and a user files a bug report), but Fedora doesn't support upgrading
from Rawhide to anything, and I have no idea at all how difficult it
is to sort out the different possible combinations of packages and
versions otherwise. 

    I also don't know whether Extras will have release cycles
matching Core with package dependencies that are guaranteed not to
conflict, but I'm guessing probably not.  There will always the the
question of non-Fedora rpms as well.

    I really really hate the way yum just craps out and quits
whenever a single package's dependencies can't be met during an
upgrade, though.  I'm tracking Rawhide, which is of course not
supported, and I know yum is being worked on (I don't know what kind
of issues are being addressed, though).  But yum, as it is, makes me
want to shoot things; it has no provision for upgrades at all.


-- 
Joseph Fannin
jhf at rivenstone.net

"That's all I have to say about that." -- Forrest Gump.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040130/75637346/attachment.sig>


More information about the fedora-devel-list mailing list