Google
  Web www.spinics.net

Re: Introducing a directory for installed test programs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 02/07/2012 12:04 PM, Ralf Corsepius wrote:
On 02/07/2012 10:36 AM, Panu Matilainen wrote:
On 02/06/2012 05:30 PM, Tom Callaway wrote:
On 02/06/2012 03:58 PM, Julio Merino wrote:
What do you mean by "multi-lib heartburn in RPM"? (Sorry, not familiar
from the term and a couple of Google searches did't provide much
insight.) FWIW, I have a preliminary atf.spec file here that provides
subpackages for libraries, tests and binaries and things seem to be
fine
to my untrained eye. I can share this file if it helps at all.

No, what I meant here is that RPM, when dealing with multi-arch support
(essentially the ability to simultaneously foo.i686.rpm and
foo.x86_64.rpm containing the same set of files, just built for the
different architecture targets), won't understand /usr/tests (or
/usr/libexec/tests for that matter).

However, if you want to be able to support this use-case, you'll need to
do something here to enable it, such as requiring that architecture be
embedded in the naming scheme, e.g. /usr/tests/xpdf-x86_64/

Um, rpm doesn't do multilib conflict resolution based on specific
directories but file type, essentially 32bit vs 64bit ELF. So if
foo-test.i686 and too-test.x86_64 both place an ELF binary into eg
/usr/libexec/tests/foo, the file from the preferred arch (normally the
64bit one) will "win", the other file is not installed at all and no
conflict is raised.

Whether you actually *want* that behavior is another question: tests and
their associated data can just as well be arch-specific or
arch-independent. The only safe assumption is to assume arch-specific
and put all test executables and associated data into arch-specific
paths (whether some variant of lib vs lib64 style differentation or by
actually embedding the arch string).

%{_libdir}/<package>/<somewhere> avoids all these issues.

Yes, except for noarch packages where %{_libdir} is not meaningful.

	- Panu -

--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging



[Home]     [Fedora Legacy]     [Fedora Desktop]     [Red Hat 9 Bible]     [Fedora Bible]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

Powered by Linux

Google
  Web www.spinics.net