This is another case of replacing a symlink with a directory. this requires a

```
%pre
if [ -L /etc/ImageMagick-7 ] ; then
  rm /etc/ImageMagick-7 ||:
fi
```

Fix submitted. `osc rq show -d 1154339`

workaround in the mean time:

`/usr/sbin/update-alternatives --remove-all ImageMagick-7`

(In reply to Marcus Rückert from comment #2)
> Fix submitted. `osc rq show -d 1154339`
> 
> workaround in the mean time:
> 
> `/usr/sbin/update-alternatives --remove-all ImageMagick-7`

Appreciate the quick response and solution, thanks.

This is an autogenerated message for OBS integration:
This bug (1220818) was mentioned in
https://build.opensuse.org/request/show/1154575 Factory / ImageMagick

Request have been accepted.

For some unrelated upgrade tests, I downgraded a machine to a 2023 snapshot.

zypper dup fails:

(2020/3247) Installing: libMagickCore-7_Q16HDRI10-7.1.1.29-2.1.x86_64 ................................................................................................................................................................[done]
(2021/3247) Installing: libMagickWand-7_Q16HDRI10-7.1.1.29-2.1.x86_64 ................................................................................................................................................................[done]
update-alternatives: error: no alternatives for ImageMagick-7
error: %prein(ImageMagick-7.1.1.29-2.1.x86_64) scriptlet failed, exit status 2
error: ImageMagick-7.1.1.29-2.1.x86_64: install failed
error: ImageMagick-config-7-SUSE-7.1.1.12-1.1.x86_64: erase skipped
error: ImageMagick-7.1.1.12-1.1.x86_64: erase skipped
(2022/3247) Installing: ImageMagick-7.1.1.29-2.1.x86_64 .............................................................................................................................................................................[error]
Installation of ImageMagick-7.1.1.29-2.1.x86_64 failed:
Error: Subprocess failed. Error: RPM failed: Command exited with status 1.

it is kinda weird that it is a symlink but update-alternatives doesnt think it owns it anymore.

*** Bug 1221355 has been marked as a duplicate of this bug. ***

Thanks, will try to look at it next week.

.

I am not able to reproduce. For one, I have TW system, where ImageMagick-7.1.1.29-3.1.x86_64 is currently installed and I haven't noticed any issue trough zypper dups trough the time until now. For second, I have tried reconstruct manually 7.1.1.12 -> 7.1.1.29 update:

:/ # zypper lr
Repository priorities are without effect. All enabled repositories share the same priority.

# | Alias | Name | Enabled | GPG Check | Refresh
--+-------+------+---------+-----------+--------
1 | new   | new  | No      | ----      | ----
2 | old   | old  | Yes     | ( p) Yes  | No
:/ #

:/ # zypper in ImageMagick
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 4 NEW packages are going to be installed:
  ImageMagick ImageMagick-config-7-SUSE libMagickCore-7_Q16HDRI10 libMagickWand-7_Q16HDRI10

4 new packages to install.
Overall download size: 2.4 MiB. Already cached: 0 B. After the operation, additional 8.4 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y
[..]
(1/4) Installing: ImageMagick-config-7-SUSE-7.1.1.12-0.x86_64 ......[done]
(2/4) Installing: libMagickCore-7_Q16HDRI10-7.1.1.12-0.x86_64 ......[done]
(3/4) Installing: libMagickWand-7_Q16HDRI10-7.1.1.12-0.x86_64 ......[done]
(4/4) Installing: ImageMagick-7.1.1.12-0.x86_64 ....................[done]
Running post-transaction scripts ...................................[done]
:/ #

:/ # update-alternatives --list ImageMagick-7
/etc/ImageMagick-7-SUSE
:/ #

:/ # ls -l /etc/alternatives/ImageMagick-7
lrwxrwxrwx 1 root root 23 Mar 18 13:35 /etc/alternatives/ImageMagick-7 -> /etc/ImageMagick-7-SUSE
:/ #

:/ # zypper mr -e new
Repository 'new' has been successfully enabled.
:/ #

:/ # zypper dup
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...

The following 3 packages are going to be upgraded:
  ImageMagick libMagickCore-7_Q16HDRI10 libMagickWand-7_Q16HDRI10

The following package is going to be REMOVED:
  ImageMagick-config-7-SUSE

3 packages to upgrade, 1 to remove.

[..]

(1/3) Installing: libMagickCore-7_Q16HDRI10-7.1.1.29-0.x86_64 .........[done]
(2/3) Installing: libMagickWand-7_Q16HDRI10-7.1.1.29-0.x86_64 .........[done]
(3/3) Installing: ImageMagick-7.1.1.29-0.x86_64 .......................[done]
Running post-transaction scripts ......................................[done]
 
:/ #

:/ # ls -l /etc/alternatives/ImageMagick-7
/usr/bin/ls: cannot access '/etc/alternatives/ImageMagick-7': No such file or directory
:/ # update-alternatives --list ImageMagick-7
update-alternatives: error: no alternatives for ImageMagick-7
:/ #

Will keep searching, but more info how to reproduce would be welcome.

(In reply to Petr Gajdos from comment #11)
> tried reconstruct manually 7.1.1.12 -> 7.1.1.29 update:

I tried again with graphics/ImageMagick's:
r661 -> r666 -> r696 -> r713
no luck.

(In reply to Christophe Marin from comment #6)
> For some unrelated upgrade tests, I downgraded a machine to a 2023 snapshot.
> 
> zypper dup fails:
> 
> (2020/3247) Installing: libMagickCore-7_Q16HDRI10-7.1.1.29-2.1.x86_64
> .............................................................................
> .............................................................................
> ......[done]
> (2021/3247) Installing: libMagickWand-7_Q16HDRI10-7.1.1.29-2.1.x86_64
> .............................................................................
> .............................................................................
> ......[done]
> update-alternatives: error: no alternatives for ImageMagick-7
> error: %prein(ImageMagick-7.1.1.29-2.1.x86_64) scriptlet failed, exit status
> 2
> error: ImageMagick-7.1.1.29-2.1.x86_64: install failed
> error: ImageMagick-config-7-SUSE-7.1.1.12-1.1.x86_64: erase skipped
> error: ImageMagick-7.1.1.12-1.1.x86_64: erase skipped
> (2022/3247) Installing: ImageMagick-7.1.1.29-2.1.x86_64
> .............................................................................
> .............................................................................
> ...................[error]
> Installation of ImageMagick-7.1.1.29-2.1.x86_64 failed:
> Error: Subprocess failed. Error: RPM failed: Command exited with status 1.

I was able to 'zypper dup' one of my boxes successfully but on two other boxes I get the above error when I dup.  The two boxes that get the above error are running Tumbleweed 20240225.  On all my boxes, I switch to TTY4 from the SDDM and login there only, and then perform the 'zypper dup' in order to prevent issues moving to Plasma 6.

(In reply to Petr Gajdos from comment #12)
> (In reply to Petr Gajdos from comment #11)
> > tried reconstruct manually 7.1.1.12 -> 7.1.1.29 update:
> 
> I tried again with graphics/ImageMagick's:
> r661 -> r666 -> r696 -> r713
> no luck.

Could not reproduce with following neither.
:/ # env | grep ZYPP
ZYPP_SINGLE_RPMTRANS=1
:/ #

(In reply to Matt Weber from comment #13)
> I was able to 'zypper dup' one of my boxes successfully but on two other
> boxes I get the above error when I dup.  The two boxes that get the above
> error are running Tumbleweed 20240225.  On all my boxes, I switch to TTY4

Interesting..

reproducer:

# rpm -e --nodeps ImageMagick
# wget https://download.opensuse.org/history/20240225/tumbleweed/repo/oss/x86_64/ImageMagick-config-7-SUSE-7.1.1.26-1.5.x86_64.rpm
# rpm -Uvh ImageMagick-*
# ln -s /etc/ImageMagick-7-SUSE /etc/alternatives/ImageMagick-7
# zypper download ImageMagick
# rpm -Uvh /var/cache/zypp/packages/repo-oss/x86_64/ImageMagick-7.1.1.29-3.1.x86_64.rpm

(In reply to David B from comment #0)
> Was running `zypper dup`
> 
> The following product is going to be upgraded:
>   openSUSE Tumbleweed  20240229-0 -> 20240301-0
> 
> The following package is going to be REMOVED:
>   ImageMagick-config-7-SUSE
> 
> 
> After downloading all packages I got this error:
> > Verifying ............................................................................................................................[done]
> > Preparing ............................................................................................................................[done]
> > Problem occurred during or after installation or removal of packages:
> > Executing the transaction failed because of the following problems:
> >     file /etc/ImageMagick-7 from install of ImageMagick-7.1.1.29-1.1.x86_64 conflicts with file from package ImageMagick-config-7-SUSE-7.1.1.26-1.6.x86_64
> 
> 
> > > sudo  zypper pa | grep ImageMag
> > i  | @System                          | ImageMagick                                                | 7.1.1.26-1.6                                         | x86_64
> > v  | openSUSE-Tumbleweed-Main-OSS     | ImageMagick                                                | 7.1.1.29-1.1                                         | x86_64
> > i+ | @System                          | ImageMagick-config-7-SUSE                                  | 7.1.1.26-1.6                                         | x86_64
> >    | openSUSE-Tumbleweed-Main-OSS     | ImageMagick-devel                                          | 7.1.1.29-1.1                                         | x86_64
> >    | openSUSE-Tumbleweed-Main-OSS     | ImageMagick-devel-32bit                                    | 7.1.1.29-1.1                                         | x86_64
> >    | openSUSE-Tumbleweed-Main-OSS     | ImageMagick-doc                                            | 7.1.1.29-1.1                                         | noarch
> >    | openSUSE-Tumbleweed-Main-OSS     | ImageMagick-extra                                          | 7.1.1.29-1.1                                         | x86_64
> 
> 
> I'm using `techpreview.ZYPP_SINGLE_RPMTRANS=1`.
> 
> Not actually a problem for me, I just removed ImageMagick and
> ImageMagick-config-7-SUSE packages before updating but I thought maybe this
> is a relevant bug.

I ended up following this suggestion on the two boxes that were unable to complete the 'zypper dup' earlier this afternoon.  From the SDDM I launched a VT and logged in:
  'sudo zypper remove ImageMagick && sudo zypper remove ImageMagick-config-7-SUSE'

  'sudo zypper refresh && sudo zypper dup' <-- This time it was successful
  'sudo shutdown -r now'
Tumbleweed launched Plasma 6 perfectly.  Going forward, I'm going to logout of any running DM and launch a VT in order to 'zypper dup' my Tumbleweed distros.  I did that on my 3rd box and it installed the new snapshot without a hitch.

* On a side note, after it came up I ran 'lsmod | grep nvidia' to check the status of my NVIDIA drivers but received no output.  I removed the NVIDIA drivers that were working in Plasma 5 (zypper remove nvidia-video-G06) and rebooted.  Then I ran 'lsmod | grep nvidia' again and discovered that they are bundled with the new Tumbleweed snapshot - so freaking cool!
https://paste.opensuse.org/pastes/2054f56137fe

(In reply to Ludwig Nussel from comment #16)
> reproducer:
> 
> # rpm -e --nodeps ImageMagick
> # wget
> https://download.opensuse.org/history/20240225/tumbleweed/repo/oss/x86_64/
> ImageMagick-config-7-SUSE-7.1.1.26-1.5.x86_64.rpm

This no longer exists for me.

I can confirm under leap 15.5.

I tried a ```sudo zypper -v dup --allow-vendor-change`` to install plasma 6 and got a failed installation of ImageMagick-config-7-SUSE.

I ignored it because it's not fundamental to the system.

The issue still occurs with ZYPP_SINGLE_RPMTRANS=1, even with 
ImageMagick-7.1.1.29-5.1, which contains the workaround from comment 7.

# zypper se -s ImageMagick
Loading repository data...
Reading installed packages...

S  | Name                      | Type    | Version      | Arch   | Repository
---+---------------------------+---------+--------------+--------+----------------------
i+ | ImageMagick               | package | 7.1.1.26-1.6 | x86_64 | (System Packages)
v  | ImageMagick               | package | 7.1.1.29-5.1 | x86_64 | Main Repository (OSS)
i+ | ImageMagick-config-7-SUSE | package | 7.1.1.26-1.6 | x86_64 | (System Packages)

# zypper dup 
Loading repository data...
Reading installed packages...
[TechPreview] $ZYPP_SINGLE_RPMTRANS=1 : New rpm install backend is enabled
...
Verifying ...[done]
(   0/2630) Executing pretrans script for: filesystem-84.87-15.3.x86_64 ...[done]
(   0/2630) Executing pretrans script for: sssd-2.9.4-2.2.x86_64 ...[done]
Preparing ...[done]
Problem occurred during or after installation or removal of packages:
Executing the transaction failed because of the following problems:
    file /etc/ImageMagick-7 from install of ImageMagick-7.1.1.29-5.1.x86_64 conflicts with file from package ImageMagick-config-7-SUSE-7.1.1.26-1.6.x86_64
    file /usr/libexec/virtiofsd from install of virtiofsd-1.10.1-4.2.x86_64 conflicts with file from package virtiofsd-1.10.1-2.1.x86_64

Maybe the update-alternatives call should be moved to %pretrans? Not sure if it's allowed to require update-alternatives in %pretrans, though.

(In reply to Martin Wilck from comment #20)
> The issue still occurs with ZYPP_SINGLE_RPMTRANS=1, even with 
> ImageMagick-7.1.1.29-5.1, which contains the workaround from comment 7.
> 
> # zypper dup 
> ...
> Verifying ...[done]
> (   0/2630) Executing pretrans script for: filesystem-84.87-15.3.x86_64
> ...[done]
> (   0/2630) Executing pretrans script for: sssd-2.9.4-2.2.x86_64 ...[done]
> Preparing ...[done]

The %pretrans of ImageMagick-7.1.1.29-5.1 was not executed...

> Problem occurred during or after installation or removal of packages:
> Executing the transaction failed because of the following problems:
>     file /etc/ImageMagick-7 from install of ImageMagick-7.1.1.29-5.1.x86_64
> conflicts with file from package
> ImageMagick-config-7-SUSE-7.1.1.26-1.6.x86_64

...although ImageMagick-7.1.1.29-5.1.x86_64 was part of the transaction?
(Or did you just clip it?)


My guess:

The %pretrans removes the file on disk, so disk content and package content do not conflict (ImageMagick).

But here /etc/ImageMagick-7 in ImageMagick and ImageMagick-config-7-SUSE conflict (their entries in the rpmdb). 
If ImageMagick-config-7-SUSE stays installed, the conflict is real. 
If ImageMagick-config-7-SUSE gets removed with or after ImageMagick, the conflict is real as well.
If ImageMagick-config-7-SUSE gets removed before ImageMagick, librpm should IMO not report an error.

we do not have a pretrans yet. because upto now doing the cleanup for rpm in %pre was the way to go.

and pretrans needs to be in lua and it is kinda dangerous.

(In reply to Marcus Rückert from comment #22)
> we do not have a pretrans yet. because upto now doing the cleanup for rpm in
> %pre was the way to go.

Ok, %pre is fine as well - as long as the disk is fixed before the package is unpacked. This is what prevents any cpio issues.

A file conflict in the rpmdb due to different content in different packages can not be fixed by any script anyway.

(In reply to Michael Andres from comment #24)

> Ok, %pre is fine as well - as long as the disk is fixed before the package
> is unpacked. This is what prevents any cpio issues.
> 
> A file conflict in the rpmdb due to different content in different packages
> can not be fixed by any script anyway.

I don't understand. What do you mean with "the disk is fixed"? With the traditional one-transaction-per-package approach, zypper can apparently overcome the file conflict with the %pre script. Or are you saying that there is no such file conflict?

What options do we have to fix issues like this such that they work with ZYPP_SINGLE_RPMTRANS=1, too?

I suggest that we add OpenQA tests for updates with ZYPP_SINGLE_RPMTRANS=1. Otherwise we'll never be able to eliminate this kind of issue.

FTR, I've set a lock on ImageMagick, so I'll be able to test alternative approaches to fix this issue.

related blog post about this and the dangers that come with it https://nordisch.org/posts/the-short-answer-is-dont/

the blog post has a bug and is being reworked.

I am about to revert update-alternatives usage removal in Factory for now and intend to solve update-alternatives differently in the near future afterwards. There are users which depend on different ImageMagick policy configurations, see bug 1122033 for one example. I am very sorry for the noise and thank you for your support.

See graphics/ImageMagick for preview, I would like to submit this change by next ImageMagick upstream version update.

if you reintroduce that under the same /etc/ImageMagick path .... it will no cause noise again for everyone who fixed their system already. changing from dir/file to symlink again causes just as much pain.

the clean(er) solution would be using a different path

(In reply to Marcus Rückert from comment #33)
> if you reintroduce that under the same /etc/ImageMagick path .... it will no
> cause noise again for everyone who fixed their system already. changing from
> dir/file to symlink again causes just as much pain.

Did you mean "it will cause", right?

Have you tried graphics/ImageMagick? What is the problem there?

I thought that majority of users, that have update-alternatives still, will not notice and Tumbleweed users, which migrated to package without update-alternatives already, will be in the same position as these systems before update-alternatives was used initially. There was an issue when introducing update-alternatives yes, but as far as I remember it was solved by %pretrans via
https://bugzilla.suse.com/show_bug.cgi?id=1122033#c37

I tried to test some udpate cases with graphics/ImageMagick and have not seen any issues so far.

In case we use other dir all, say, SLE users, which touched /etc/ImageMagick will have to migrate to new dir, no?
 
> the clean(er) solution would be using a different path

It crossed my mind as well, I do not reject it at all, but need to have an argument against the above solution.

(In reply to Petr Gajdos from comment #34)
> I thought that majority of users, that have update-alternatives still, will
> not notice and Tumbleweed users, which migrated to package without
> update-alternatives already, will be in the same position as these systems
> before update-alternatives was used initially. There was an issue when
> introducing update-alternatives yes, but as far as I remember it was solved
> by %pretrans via
> https://bugzilla.suse.com/show_bug.cgi?id=1122033#c37

I see %pretrans only indirectly mentioned in that comment. How exactly did the solution look like?

Hi Martin,

thanks for your reply.

(In reply to Martin Wilck from comment #35)
> I see %pretrans only indirectly mentioned in that comment. How exactly did
> the solution look like?

in 15sp4 trough bug 1122033
$ osc cat SUSE:SLE-15-SP4:Update ImageMagick ImageMagick.spec | grep -A 10 %pretrans

in Factory (past)
$ osc cat -r 286 openSUSE:Factory/ImageMagick ImageMagick.spec | grep -A 10 %pretrans

in graphics/ImageMagick
$ osc cat graphics/ImageMagick ImageMagick.spec | grep -A 10 %pretrans


The more I think about it: in 2019, the original idea was (perhaps false, yes) to have alternative whole config directory, but I think just policy.xml could be sufficient as it is only file variable across the security policies.

We have users (bug 1122033) which want to use alternative security policy and want to switch between them just by installing corresponding package. Perhaps we could provide everything except policy.xml in new /etc/IMagick-7 (or so, /etc/ImageMagick was an u-a link in SLE12 already) inside main ImageMagick package and then /etc/IMagick-7/policy.<policy>.xml in few different subpackages ImageMagick-policy-<policy>. Not completely sure what would do the /etc/IMagick-7/policy.xml link as update-alternatives seem to get abandoned. Perhaps something like 12sp5/apache2?

Other ideas welcome

well everyone who switched to the new setup with it being a directory again will again need manual work or ugly and dangerous %pre(trans) scriptlets.

that's why i suggest switch to a new path if it isnt a big problem and avoid the problems all together.

(In reply to Petr Gajdos from comment #36)

> in Factory (past)
> $ osc cat -r 286 openSUSE:Factory/ImageMagick ImageMagick.spec | grep -A 10
> %pretrans
> 
> in graphics/ImageMagick
> $ osc cat graphics/ImageMagick ImageMagick.spec | grep -A 10 %pretrans

Am I understanding correctly that the breakage I saw in comment 20 was caused by the removal of the existing %pretrans scriptlet?

(In reply to Martin Wilck from comment #38)
> (In reply to Petr Gajdos from comment #36)
> 
> > in Factory (past)
> > $ osc cat -r 286 openSUSE:Factory/ImageMagick ImageMagick.spec | grep -A 10
> > %pretrans
> > 
> > in graphics/ImageMagick
> > $ osc cat graphics/ImageMagick ImageMagick.spec | grep -A 10 %pretrans
> 
> Am I understanding correctly that the breakage I saw in comment 20 was
> caused by the removal of the existing %pretrans scriptlet?

No. The problem you had seen was the migration from link to dir, if I am not mistaken.

For the information, the revert of update-alternatives removal is now in Factory trough https://build.opensuse.org/request/show/1176179
(unfortunately, I have realized that post-mortem as I missed the obs notification mail)

In 
https://build.opensuse.org/project/show/home:pgajdos:magick-no-ua
there is a variant without update alternatives. To summarize, it:
1. uses a new /etc/IMagick-7 dir (question is, whether this is reasonable,
   given that the revert is in factory yet)
2. ships policies under %{_datadir}/libMagickCore%{libspec}%{clibver}/policies
   together with imagick-set-policy helper script which is supposed make a
   link /etc/IMagick-7/policy.xml to one of that policy 
3. policies can be installed in parallel, imagick-set-policy will choose the 
   'most secure one' even if they can not be exactly linearly ordered to
   provide  /etc/IMagick-7/policy.xml; other policies installed on the same
   system can be used together with MAGICK_CONFIGURE_PATH
4. imagick-set-policy is run from %post/%postun of individual configuration
   variant packages and the main package; it can be used even directly, for
   testing purposes

We can choose (again, given that the revert is in factory already) the less intrusive change and replace the update-alternaives with the script analogous to imagick-set-policy to provide the /etc/ImageMagick-7 link to variants instead of update-alternatives.