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
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.
Severity: normal => criticalPriority: Normal => release_blockerCC: (none) => doktor5000, marja11Assignee: bugsquad => lists.jjorge
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.
(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. Hi, I am sorry, I missed your comment and I added again enigmail into thunderbird.spec (version 60.3.3-3.mga7). Best regards, Nico
CC: (none) => nicolas.salguero
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) ################ tldr; * /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
Closing as we can use enigmail for long in MGA7
Status: NEW => RESOLVEDResolution: (none) => FIXED