In ikiwiki-2.60, external plug-ins are yet again installed using 'cp -a' instead of 'install -m 755'. This poses a problem on at least FreeBSD 6.x, since the cp(1) command doesn't support the '-a' flag.

The change in question (from 2.56 to 2.60) can be seen here:

-       for file in `find plugins -maxdepth 1 -type f ! -wholename plugins/.\*`; do \
-               install -m 755 $$file $(DESTDIR)$(PREFIX)/lib/ikiwiki/plugins; \
-       done; \
+       for file in `find plugins -maxdepth 1 -type f ! -wholename plugins/.\* | grep -v demo`; do \
+               cp -a $$file $(DESTDIR)$(PREFIX)/lib/ikiwiki/plugins; \
+       done \

Please restore the old behaviour of using 'install'

-- HenrikBrixAndersen

I use cp -a because I don't want non-executable files to be installed executable. (Causes breakage with setup file creation code) I really wish *BSD could get out of the 70's in this area.. --Joey

Well, really what's happening here is that *BSD (along with, for example, Solaris) is adhering rather closely to the Single UNIX Specification, whereas -a is a nonstandard option added to the GNU variant of cp (a habit Richard Stallman never really got under control). To install ikiwiki on Solaris I had to replace all uses not only of cp but also of install and xgettext with the GNU embrace-and-extend variants, and make sure I had those installed. That really is a bit of a PITA.

I think there's an opportunity here for a really clean solution, though.

Why not do the installation in pure Perl?

The file manipulations being done by cp and install would be straightforward to code in Perl, and there really isn't a complicated build requiring the full functionality of gmake. gxgettext I'm not so sure about, but even getting rid of almost all the nonstandard-utility dependencies would be a win.

The idea is that if you're distributing a Perl-based app, one thing you'll always be absolutely certain of in the target environment is a working Perl. The fact that the current build starts out in Perl, but uses it to write a Makefile and then hand off to other utilities that are less dependably compatible across platforms is a disadvantage.

A pure-Perl install can also query the very Perl it's running in to determine the proper places to install files, and that will be less error-prone that making a human edit the right paths into some files. It would be quite useful here, actually, where we have several distinct Perl builds installed at different paths, and ikiwiki could be correctly installed for any one of them simply by using the chosen Perl to run the install. That means this would also be a complete solution to todo/assumes system perl. --ChapmanFlack

Joey: How about the following patch, then? -- HenrikBrixAndersen

--- Makefile.PL.orig    2008-08-16 14:57:00.000000000 +0200
+++ Makefile.PL 2008-08-16 15:03:45.000000000 +0200
@@ -67,9 +67,12 @@ extra_install:
    done

    install -d $(DESTDIR)$(PREFIX)/lib/ikiwiki/plugins
-   for file in `find plugins -maxdepth 1 -type f ! -wholename plugins/.\* | grep -v demo`; do \
-       cp -a $$file $(DESTDIR)$(PREFIX)/lib/ikiwiki/plugins; \
-   done \
+   for file in `find plugins -maxdepth 1 -type f ! -wholename plugins/.\* ! -name \*demo\* -name \*.py`; do \
+       install -m 644 $$file $(DESTDIR)$(PREFIX)/lib/ikiwiki/plugins; \
+   done
+   for file in `find plugins -maxdepth 1 -type f ! -wholename plugins/.\* ! -name \*demo\* ! -name \*.py`; do \
+       install -m 755 $$file $(DESTDIR)$(PREFIX)/lib/ikiwiki/plugins; \
+   done

    install -d $(DESTDIR)$(PREFIX)/share/man/man1
    install -m 644 ikiwiki.man $(DESTDIR)$(PREFIX)/share/man/man1/ikiwiki.1