;)

Dont do that then ;-) seriously ... explain what the real usecase is.. so we can give you some ideas..

in former realease of packaging to much and ominous scripts were used. some historical internal requirements... i want to avoid that package is installed as update. best way would be to enforce that old release is uninstalled before current package gets installed. Thanks, Andre -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Am Donnerstag, 16. Juli 2009 15:11:26 schrieb Dominique Leuenberger:

...

...

...

On 7/16/2009 at 15:04, Andre Hübner wrote:

;)

...

Dont do that then ;-) seriously ... explain what the real usecase is.. so we can give you some ideas..

in former realease of packaging to much and ominous scripts were used. some

historical internal requirements... i want to avoid that package is installed as update. best way would be to enforce that old release is uninstalled before current package gets installed.

That sounds like a Conflicts: $oldpkg

Alternative is to use: Provides: $oldpackage Obsoletes: $oldpackage than the old package will get deinstalled and the new one gets installed. Downside is that the old package can not be installed in parallel. bye adrian

This will stop RPM from installing new package while old package is installed.

-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Andre Hübner wrote:

...

That sounds like a Conflicts: $oldpkg

I tried but i think i cant use it. Its in my case not a conflict with other package which could be named as conflict. In my deplorable case the package ""conflicts"" with former release. name/version is still the same, just release is changed. adding a conflict to$pkg < %{version}-%{release} does not work/gets ignored. all i want ist that package is not used as update, all former releases should be uninstalled before installing this release, because i expect some trouble by these old %preun scriplets ;(

Use provides and obsoletes like Adrian suggested.

Thanks, Andre

-- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Community Multiplier Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Andre needs a way to be sure that rpm -Uhv foo-1.1 does not work, as he does not trust the scripts from foo-1.0

The provides / obsolete won't help him (as it's implicit in this situation anyhow).

yes, thats it. tomorrow i will try with testing existence of file and do an exit if file exists. This will force the user to uninstall foo-1.0 and install foo-1.1 after that explicit uninstall. testing existence of file seems to be most acceptable at the moment... Thanks, Andre -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Uh, please *never* do an exit 1 in a pre/postinstall scriptlet. It'll abort in the middle of the transaction and the user will have an inconsistent system state.

And the clean way to avoid installation are only explicit conflcts/obsoletes entries in spec? Other chances to do this if only in scripts some annoying conditions could be checked? Thanks, Andre -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Le jeudi 16 juillet 2009, à 17:44 +0200, Michael Schroeder a écrit :

On Thu, Jul 16, 2009 at 05:32:44PM +0200, Andre Hübner wrote:

...

yes, thats it. tomorrow i will try with testing existence of file and do an exit if file exists.

Uh, please *never* do an exit 1 in a pre/postinstall scriptlet. It'll abort in the middle of the transaction and the user will have an inconsistent system state.

Hrm, if it's so easy to break the system, shouldn't rpm do something to avoid this? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 16/07/09 11:32, Andre Hübner wrote:

yes, thats it. tomorrow i will try with testing existence of file and do an exit if file exists.

No! you never _ever_ do that.

This will force the user to uninstall foo-1.0 and install foo-1.1 after that explicit uninstall. testing existence of file seems to be most acceptable at the moment...

what kind of file are you testing before exit ? is it a configuration file ? a binary ? this smells pretty fishy to me.. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

...

within rpm installation of package x i try in %pre to find out with rpm -q if package y is already installed. Seems that in rpm-3.x rpmdb is locked from the start, same script works with rpm-4.x its not a dependency/conflict etc., all i want is to echo some information if package y is also installed. Do i have some alternatives?

Dont do that then ;-) seriously ... explain what the real usecase is.. so we can give you some ideas..

i think i found a solution. reason for my problem is that during upgrade the %postun of old package runs after %post of new package. this removes some changes made by %post of new package. uninstall --> install is working because order of scriptlets is like expected. is the %posttrans section useable to make sure that last action is triggered by new package? %posttrans is new to me, i found it in a fedora-wiki... otherwise i have to fix the few affected machines by hand and in new rpm i can consider special situation like described here: http://en.opensuse.org/Packaging/Guidelines#Running_scriptlets_only_in_certa... this should fix my problem also at further packageupgrades. i know that to much scripting in rpms should be avoided, but its just for internal puposes and sometimes special situations require special solutions... Thanks, Andre -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Well, posttrans is run at the end of the transaction, so if some other package fails and the transaction is aborted it'll never be run. Our gnome folks use it for the same purpose.

seems that %posttrans is not known to rpm 3.x, in 4.x it works. would be to easy... but reduces problematic machines to ~5, i can fix them by hand and next rpm which coniders install/upgrade situation on %postun should fix the whole thing. Thanks, Andre -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org