Porting atf - violating the layout of the ports-filesystems

Rainer Müller raimue at macports.org
Thu Jul 15 01:17:46 PDT 2010


On 2010-07-12 19:21 , Julio Merino wrote:
> [ Rainer, Ivan: Sorry for sending this twice to you, but the strict
> posting rules of the mailing list caused the original mail to be
> dropped.  I had to subscribe and send the email again. ]

Sorry, you need to subscribe to post as an anti-spam measurement.

> First of all, putting the tests anywhere under prefix/share/ is plain
> wrong.  Tests are executables and therefore they are not shareable
> across machines of different platforms.  Therefore, they do not belong
> in share (per the traditional definition of share).  (A reasonable
> possibility would be to stick them under prefix/libexec/.  This is
> mostly OK, but is also wrong in the sense that they are not private
> binary programs intended to be executed by some other binary/library.
> They are really supposed to be exposed to the user.)

I agree with you. Actually I didn't look that close at the tests and
missed that they are executable binaries.

> Second, putting the tests under prefix/share/atf/tests/ is also wrong.
>  atf will create a subdirectory called 'atf' under the tests
> directory, which means you'll end up with prefix/share/atf/tests/atf/,
> which is obviously redundant.
> 
> So the place for tests must be somewhere else and this is why atf
> creates a new top-directory layout under prefix.  The point of this
> tree is to allow any package that uses atf to put its tests there
> under a subdirectory named after the package name.  This way, you have
> a central place in your system where you can go, run the tests, and
> ensure things work.
> 
> Imagine if every single atf-ified package put its tests in
> prefix/tests/<package-name>/ -- it'd then be trivial to run the tests
> for all the software you have installed and know that the software
> works flawlessly on your current OS/hardware platform.  And even
> better, you could do that periodically to ensure that, e.g. OS
> upgrades do not screw things up.
> 
> Now, I know that installing the tests as part of the package[1] is a
> completely different paradigm to the one offered by most testing
> frameworks (I am not aware of any other that intends to do something
> similar).  Therefore, you cannot apply the same logic to the atf
> package as you would for others, and I would really ask you to
> consider allowing the creation of the prefix/tests/ directory.

Okay, so this is quite different from what other ports in MacPorts
usually do. But the name "tests" is quite generic. I see the NetBSD
hier(7) explicitely lists ${prefix}/tests/ as a path for atf tests. This
works there as that is where it originated. I am not inclined to change
our porthier to add ${prefix}/tests yet as that is not in wide-spread
use, so the atf port would have to declare a mtree violation.

Is any other system packaging atf at this time?

Rainer


More information about the macports-users mailing list