On Thu, Mar 19, 2009 at 02:12:01PM +0100, Stanislav Brabec wrote:
> I have been thinking about it as well. Such simple definition may work
> in simple cases (foo-1.0 replaced by foo-1.1), but it will be
> problematic for more complicated cases:
> 
> 
> 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.

> 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.

> 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.

Cheers,
  Michael.

-- 
Michael Schroeder                                   m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to