Bug 340571

Er.. is a2ps a multilib package?

Because it ships liba2ps in the system library directories, yes.

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.

If it wasn't clear above, I'll investigate and try to do 
patches...

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

Created attachment 294705 [details]
follow emacs guidelines and avoid multilib conflict

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

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
-}
-

Thanks!  All built in 4.13b-71.fc9.