[Rpm-maint] upgrade process

[Stanislav Brabec]

Michael Schroeder wrote in Thu 03/19 2009 at 15:35 +0100:

> > 1) Imagine that package foo-1 is going to be split to three
> > sub-packages: foo-core-2, foo-plugins-base-2 and foo-plugins-extra-2.
> > Now we are going to upgrade from foo-1 to foo-core-2+foo-plugins-base-2,
> > omitting the foo-plugins-extra-2. Is it an upgrade or not?
> 
> If it obsoletes another package it's an upgrade.

And what if the action you need is say foo-extra-update and foo-extra
update was a part of foo-1 and later foo-plugins-extra-2?

In real life, many actions are not relevant to package, but to an exact
file name:
- init script restart
- purge of no more used directory
- ...

> > 2) Imagine that package foo needs to run "adduser fooser" during the
> > first installation and it should call "deluser fooser" on package
> > removal. Now imagine that yet another package foof needs to do the same
> > for the same user. Even after package foo removal, fooser should be
> > defined. It should be removed only if none of foo and foof will be
> > present.
> 
> This has an easy solution: *never* call deluser. You don't know if
> there are some files owned by the user lurking somewhere in the
> filesystem and you sure don't want them to belong to some other user
> after the next adduser call.

Well, in case of adduser, it keeps just one orphan line. But packages
may keep several megabytes of cache files, which become obsolete if all
its consumers are removed.

> > 3) Imagine that non-conflicting packages foo and package oof provide the
> > same function and both want to install compatibility script or symlink
> > foo-or-oof. It should exist, if any of foo or oof are installed.
> > 
> > Possible solution:
> > Create a virtual symbol foo-or-oof-script and then continue with 2).
> > %postnew foo-or-oof-script and %postrm foo-or-oof-script should do what
> > you expect.
> 
> Sounds like a job for update-alternatives. If you don't want that,
> use %verify(not md5 size mtime link) and don't use a scriptlet at
> all.

Yes, update-alternatives is the cleanest solution in this case.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec at suse.cz
Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                                    http://www.suse.cz/