Bug 340571 - multiarch conflicts in a2ps
Summary: multiarch conflicts in a2ps
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: a2ps
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F8Target
TreeView+ depends on / blocked
 
Reported: 2007-10-19 21:30 UTC by Bill Nottingham
Modified: 2014-03-17 03:09 UTC (History)
2 users (show)

Fixed In Version: 4.13b-71.fc9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-13 11:05:50 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
follow emacs guidelines and avoid multilib conflict (4.32 KB, patch)
2008-02-12 22:16 UTC, Patrice Dumas
no flags Details | Diff

Description Bill Nottingham 2007-10-19 21:30:37 UTC
a2ps (or one of its subpacakges) has multiarch conflicts when installed for both i386 and x86_64 in the Fedora development tree. For help in resolving them, see http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks. 

  file /usr/share/a2ps/README from install of a2ps-4.13b-69.fc8 conflicts with file from package a2ps-4.13b-69.fc8
  file /usr/share/emacs/site-lisp/a2ps-print.elc from install of a2ps-4.13b-69.fc8 conflicts with file from package a2ps-4.13b-69.fc8
  file /usr/share/emacs/site-lisp/a2ps.elc from install of a2ps-4.13b-69.fc8 conflicts with file from package a2ps-4.13b-69.fc8

(Note that this is an automated bug filing.)
It would be nice to have these bugs fixed by the beta of Fedora 9.

Comment 1 Tim Waugh 2008-01-15 17:52:55 UTC
Er.. is a2ps a multilib package?

Comment 2 Bill Nottingham 2008-01-15 18:13:10 UTC
Because it ships liba2ps in the system library directories, yes.

Comment 3 Patrice Dumas 2008-02-12 18:30:53 UTC
No it is not a real multilib package. Separating the libs is unuseful,
the libs are only required by a2ps. It adds an unneeded package
(it would be completely different if there was an a2ps-devel package).

# repoquery --whatrequires liba2ps.so.1
a2ps-debuginfo-0:4.13b-69.fc8.i386
a2ps-0:4.13b-69.fc8.i386

The conflicts may be investigated and fixed, but I find the current fix
suboptimal.

There is a timestamp within the README file. As for the .elc, I guess that
the emacs packaging guidelines are not followed to begin with.


Comment 4 Patrice Dumas 2008-02-12 18:46:04 UTC
If it wasn't clear above, I'll investigate and try to do 
patches...

Comment 5 Patrice Dumas 2008-02-12 22:16:06 UTC
I attach a patch that sets reproducible timestamp in the 
%_datadir/README file. Also more timestamps kept (not all).
And tries to comply to the emacs add-ons guidelines.

I think that if th epatch is applied, the libs subpackage can be
(I can do that too if you want to).

Comment 6 Patrice Dumas 2008-02-12 22:16:56 UTC
Created attachment 294705 [details]
follow emacs guidelines and avoid multilib conflict

Comment 7 Patrice Dumas 2008-02-12 22:17:41 UTC
(In reply to comment #5)

> I think that if th epatch is applied, the libs subpackage can be
> (I can do that too if you want to).

Should have been, I think that if the patch is applied, the libs 
subpackage can be removed (I can do that too if you want to).

Comment 8 Patrice Dumas 2008-02-13 08:51:10 UTC
It also seems to me the following may be removed, and it
works without in my test:

-### FIXME ###
-inst()
-{
-mkdir -p %{buildroot}%{_datadir}/emacs/site-lisp/
-for f in contrib/emacs/*.el; do \
-  install -p -m 0644 $f %{buildroot}%{_datadir}/emacs/site-lisp/ ; done
-}
-


Comment 9 Tim Waugh 2008-02-13 11:05:50 UTC
Thanks!  All built in 4.13b-71.fc9.


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