Roland McGrath wrote:
- how can we stop separate-debug-info destroying the test-suite RPM's
contents
For instance, frysk's test-suite includes sys-rooted source and
separate-debug-info tests; unfortunatly the RPM packaging process
corrupts these by trying to make sys-rooted source and
separate-debug-info rpms out of them ... :-) We'd like to avoid this
:-), in effect, have a way to prevent all such post "make install"
manipulation on certain files.
That is actually not very easy at all. All those things are in several
scripts and they all pretty much do a "find $RPM_BUILD_ROOT" of some sort.
We can figure out arcane ways to dodge each one, but I think it will wind
up very fragile. I think the only way to win is not to play the game.
Alternative approaches that come to mind:
These all also seem arcane and dodgy, surely there's a way to stipulate
both that a file is part of the rpm and that its contents shouldn't be
manipulated.
I'll note the second suggestion; the result comes closest to what one
would expect.
Andrew
1. Put all the test data files into their own rpm, built from their own
src.rpm separate from any installed programs of any kind. It's not so
hard to completely disable all post-processing for the whole .spec, e.g.:
%define __spec_install_post %{nil}
The rpm containing the test suite can Require: the test-data rpm.
2. Fake out rpm by unpacking in %post and using %ghost.
That is, include in the rpm a /usr/lib/frysk/test-data.tar.bz2 file.
Use e.g.:
tar cf - files... | bzip2 -9 > test-data.tar.bz2
tar tjf test-data.tar.bz2 | sed 's/^/%ghost /' > datalist
%files -f datalist
/usr/lib/frysk/test-data.tar.bz2
/usr/lib/frysk/test-data
%post
tar -jf /usr/lib/frysk/test-data.tar.bz2 -x -C /usr/lib/frysk/test-data
3. Avoid the problem entirely. Just include test-data.tar.bz2 in the rpm.
Make the test procedure (top driving shell script or whatever) do:
mkdir temp-place-for-test-run
tar -C temp-place-for-test-run -xf /usr/lib/frysk/test-data.tar.bz2
run-tests --sysroot=temp-place-for-test-run
rm -rf temp-place-for-test-run
I would tend towards #3 I think.
Thanks,
Roland
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
