Bug 23918 - enigmail package missing / no clean update from mga6
Summary: enigmail package missing / no clean update from mga6
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: release_blocker critical
Target Milestone: ---
Assignee: José Jorge
QA Contact:
URL: https://ml.mageia.org/l/arc/dev/2018-...
Depends on:
Reported: 2018-11-28 12:37 CET by Christian Lohmaier
Modified: 2018-12-11 19:39 CET (History)
3 users (show)

See Also:
Source RPM: thunderbird-60.3.1-1.mga7.src.rpm
Status comment:


Description Christian Lohmaier 2018-11-28 12:37:28 CET
n http://svnweb.mageia.org/packages?view=revision&revision=1319076
the package thunderbird-enigmail was nuked from cauldron with a
message of 

   "remove enigmail to package it separately" 

but apparently that didn't happen/was forgotten?

What is the status of this? If if enigmail package is dropped
completely, would that be a candidate for obsoletes?

As it is now, the missing package breaks the update to cauldron when the user had the enigmail package installed. If the package is dropped completely, there should be readme.urpmi or similar that tells the user to install it separately and thunderbird should obsolete it (IMHO, but see below)

following not related to the enigmail situation, but more general
stuff re magia update path/obsolete policy - Honestly I'm a little
confused about the obsoletes policy in mageia..
My bug https://bugs.mageia.org/show_bug.cgi?id=23786 " cauldron should
obsolete libdnf1 & libsolv0" was closed as invalid, basically meaning:
when you update from mga6 to mga7, there won't be clear update path,
you have to manually agree to remove packages that have no longer
fulfilled dependencies and are completely replaced in mga7, so matching
"When a package is no longer needed in the distribution it should be
obsoleted and removed from cauldron." (
https://wiki.mageia.org/en/Packaging_guidelines#Obsoleting_a_package )
Whereas just recently Thierry Vignaud (who closed my report) suggested
to add libstdc++5-devel to task-obsolete or similar to solve a
update/auto-orphans issues reported to the list. - don't really get
how that is a different case.

for reference: this had been posted to the mailing list early november without any reply.. https://ml.mageia.org/l/arc/dev/2018-11/msg00046.html
Comment 1 Marja Van Waes 2018-11-29 09:02:39 CET
Setting this to release blocker for the missing enigmail.

Please start a separate thread on dev ml about obsoleting, you can add that I'd like to better understand it, too!

Assiging to Zézinho, who removed enigmail.

CC'ing the registered maintainer.

Assignee: bugsquad => lists.jjorge
CC: (none) => doktor5000, marja11
Priority: Normal => release_blocker
Severity: normal => critical

Comment 2 José Jorge 2018-12-05 14:40:27 CET
It just needs to be packaged separately, like fedora does :


I will do it ASAP.
Comment 3 Nicolas Salguero 2018-12-08 08:36:10 CET
(In reply to José Jorge from comment #2)
> It just needs to be packaged separately, like fedora does :
> https://src.fedoraproject.org/rpms/thunderbird-enigmail/blob/master/f/
> thunderbird-enigmail.spec
> I will do it ASAP.


I am sorry, I missed your comment and I added again enigmail into thunderbird.spec (version 60.3.3-3.mga7).

Best regards,


CC: (none) => nicolas.salguero

Comment 4 Christian Lohmaier 2018-12-11 19:39:26 CET
FYI: Fixes the update-path for me, so could update my main desktop to cauldron now (needs the new HW-support for Ryzen w/ Vega).

One small issue:
The post / postun script seems broken / pointless.

both clear 
/usr/lib64/thunderbird/components/compreg.dat and /usr/lib64/thunderbird/components/xpti.dat 
(which arguably should never end up in /usr to begin with, and in fact do not exist in my install, so clearing that is OK)

but they also both try to run
    HOME="$TB_TMPDIR" LD_LIBRARY_PATH="/usr/lib64/thunderbird" /usr/lib64/thunderbird/thunderbird-bin -nox -register

but that gives an error during installation:

Running Thunderbird as root in a regular user's session is not supported.  ($XDG_RUNTIME_DIR is /run/user/1000 which is owned by cl.)

so likely the command didn't do anything.

The other issue is that the scripts don't distinguish between update and first unstall/final removal, and even worse it is not a postuninstall but *pre*uninstall, that for sure doesn't give the expected result.

I assume it is meant to update the list of installed extensions in some form. Thus updating will cause:

* Version_new's files get installed
  → postinstall script runs, with a potentially a handful of version_old's files still lying around
* preuninstall script of version_old gets run
  → doing exactly the same thing as the previous run, with a mix of the files of the new package, with not-yet-removed files of the old package still on disk
* version_old's files that are left over get removed

→ extension registry might potentially refer to no-longer existing files

so at least the preuninstall should be moved to postuninstall, so no mix of the extension's version shall exist anymore.

If you want to be extra thorough, check $1 (the number of packages on the system when the script runs) in the postinstall script, to skip it in the update case (since postuninstall of the old package will run it, and that is the point where the set of files is the one that should be considered)


* /pre/uninstall for sure is wrong
* scripts don't seem to be necessary/they don't ensure a env where they run successfully and also the exit status is not checked
* ideally distinguish between update and installation/removal

Note You need to log in before you can comment on or make changes to this bug.