Bug 340571 - multiarch conflicts in a2ps
multiarch conflicts in a2ps
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: a2ps (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F8Target
  Show dependency treegraph
 
Reported: 2007-10-19 17:30 EDT by Bill Nottingham
Modified: 2014-03-16 23:09 EDT (History)
2 users (show)

See Also:
Fixed In Version: 4.13b-71.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-13 06:05:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Bill Nottingham 2007-10-19 17:30:37 EDT
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 12:52:55 EST
Er.. is a2ps a multilib package?
Comment 2 Bill Nottingham 2008-01-15 13:13:10 EST
Because it ships liba2ps in the system library directories, yes.
Comment 3 Patrice Dumas 2008-02-12 13:30:53 EST
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 13:46:04 EST
If it wasn't clear above, I'll investigate and try to do 
patches...
Comment 5 Patrice Dumas 2008-02-12 17:16:06 EST
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 17:16:56 EST
Created attachment 294705 [details]
follow emacs guidelines and avoid multilib conflict
Comment 7 Patrice Dumas 2008-02-12 17:17:41 EST
(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 03:51:10 EST
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 06:05:50 EST
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.