Bug 709136

Summary:	emacs bytecompiled files in new libidn conflict between i686 & x86_64
Product:	[Fedora] Fedora	Reporter:	Stijn Hoop <stijn>
Component:	libidn	Assignee:	Ville Skyttä <ville.skytta>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	mattdm, mlichvar, ville.skytta
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	1.22-3	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-05-31 18:43:38 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Stijn Hoop 2011-05-30 19:24:28 UTC

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

Comment 1 Matthew Miller 2011-05-31 13:06:08 UTC

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).

Comment 2 Ville Skyttä 2011-05-31 15:38:26 UTC

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.

Comment 3 Miroslav Lichvar 2011-05-31 16:04:09 UTC

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?

Comment 4 Ville Skyttä 2011-05-31 18:43:38 UTC

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 :)