[Fedora-packaging] Introducing a directory for installed test programs

Panu Matilainen pmatilai at laiskiainen.org
Tue Feb 7 09:36:17 UTC 2012


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

	- Panu -



More information about the packaging mailing list