Hide Forgot
Description of problem: Version 1.22-2 of libidn adds byte-compiled files for emacs, however this leads to installation errors of libidn on an x86_64 system where the i686 version is also present. On my system libidn.i686 is needed for nspluginwrapper.i686. Version-Release number of selected component (if applicable): libidn-1.22-2.fc16 How reproducible: Always Steps to Reproduce: [stijn@pounce] <~> sudo yum -y update libidn Loaded plugins: langpacks, presto, refresh-packagekit Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package libidn.i686 0:1.22-1.fc16 will be updated ---> Package libidn.x86_64 0:1.22-1.fc16 will be updated ---> Package libidn.i686 0:1.22-2.fc16 will be an update ---> Package libidn.x86_64 0:1.22-2.fc16 will be an update --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: libidn i686 1.22-2.fc16 rawhide 207 k libidn x86_64 1.22-2.fc16 rawhide 207 k Transaction Summary ================================================================================ Upgrade 2 Package(s) Total size: 414 k Downloading Packages: Running Transaction Check Running Transaction Test Transaction Check Error: file /usr/share/emacs/site-lisp/idna.elc conflicts between attempted installs of libidn-1.22-2.fc16.i686 and libidn-1.22-2.fc16.x86_64 file /usr/share/emacs/site-lisp/punycode.elc conflicts between attempted installs of libidn-1.22-2.fc16.i686 and libidn-1.22-2.fc16.x86_64
Also: I don't have emacs installed, and this now wants to pull in something called "emacs-filesystem". Since libidn is a core library that really can't be removed, that seems like uncalled-for dependency bloat (even if it is a small package).
emacs-filesystem contains 3 directories, nothing more (rpm -qi says Size: 0 here), those dirs would be created without any package owning them anyway when packages dropping files to those dirs are installed (such as the previous libidn package did), so I really cannot see any basis for "dependency bloat" there. Having a dependency on it is mandated by the Emacs packaging guidelines in cases such as this one: http://fedoraproject.org/wiki/Packaging:Emacs Byte compiling elc is also mandated by those guidelines. The conflict however is my bad and I'll fix it; Miroslav, I intend to split out a noarch -emacs subpackage out of libidn containing those files and add a emacs(bin) dependency to it (see the guidelines above) if that's fine with you - let me know and I'll proceed.
That's fine with me. Thanks. I assume the conflict is caused by the timestamp in the generated file, perhaps it would be useful to remove it in the %{_emacs_bytecompile} macro to avoid such conflicts when a noarch subpackage is not desired?
Ok, should be fixed in 1.22-3. Yep, it'd be nice if there was a way to avoid comments/headers in *.elc that cause conflicts like this, but I'm afraid there's no official way in Emacs to do that. The variables things are the timestamp, the user-mail-address (or user@host), and the path to the *.el file. Those could be set to constant values by some clever hacks in the emacs command line, but as there's no real API for that I suppose it'd be somewhat fragile. And I suppose that stuff shouldn't be simply sed'd away either because Emacs' bytecomp.el itself seems to be very cautious when it replaces some comment headers in some scenarios, apparently need to keep file positions intact or something... anyway that's not something that we should be discussing in this bug :)