generate a relocatable xz executable

[RJVB (René Bertin)]

IIRC one of the hurdles that's always come up when discussing the feasibility of making xz compression of software images the default is the fact that xz is currently distributed as a port (and IIRC there were some issues with including it as a "base" dependency).

Indeed, this is a conundrum each time I want to update port:xz itself.

Now that the xz compression idea has come up again I realised that one way to get around this would be to generate a static version of the xz command and install that somehow, somewhere as a fallback.

The attached patchfile adds an xz_r command (I think the traditional suffix for indicating a relocatable version of a command is _r, no?).

I don't have any brilliant ideas how to use this for the intended purpose. Apparently there is nothing like a pre-deactivate phase where one could move the xz_r command to a fallback location, so the only option I see that doesn't require hacking "base" would be to install xz_r in port:xz's post-activate phase (into /opt/local/sbin for instance, renamed to xz), so that it doesn't get deactivated. Evidently that'd be a stop-gap solution.

[RJVB (René Bertin)]

add an xz_r build target (requires running the included autogen.sh)

[larryv (Lawrence Velázquez)]

Replying to RJVB:

the only option I see that doesn't require hacking "base" would be to install xz_r in port:xz's post-activate phase (into /opt/local/sbin for instance, renamed to xz), so that it doesn't get deactivated.

So this wouldn’t get removed when xz is deactivated or uninstalled? Why would we want that behavior?

[RJVB (René Bertin)]

It's the only option I see at the moment that doesn't involve changing the base layer and that ensures there's always an xz command available to allow ports to be activated or installed from .tar.xz archives, even when updating port:xz itself. Well, the only option that doesn't have users do the copying themselves.

The intention of this ticket is just to give an upbeat by sharing a patch to the automake source to build an additional, relocatable xz command. Or rather, one that doesn't depend on liblzma.dylib; getting rid of the libintl dependency properly (if not configuring with --disable-nls) requires the 2nd patch I'll be uploading. For some reason libintl.la is missing from port:gettext which means that just using -static-libtool-libs isn't enough.

[danielluke (Daniel J. Luke)]

I would think we would want to handle this like the other binaries we install for base to use (ie base/vendor). Building static isn't necessary.

[RJVB (René Bertin)]

Sure, but that can only be done in the next release. In the meantime it has been possible for quite a while to compress locally built software archives with xz (portarchivetype txz in macports.conf). Which works fine until you try to update xz or one of its dependencies.

[raimue (Rainer Müller)]

I agree with Daniel. If we always want xz available, it needs to be shipped from the vendor directory with base. I see no point in doing this without a base release.

[RJVB (René Bertin)]

Let me repeat that the feature to use xz compression already exists, and is documented in macports.conf . Providing a way to build a static xz executable and documenting how to use it can be seen as a courtesy to users who'd like to benefit from this more efficient compression, and doesn't at all stand in the way of an implementation fix in a future release. It's always been the main goal of this ticket to suggest this.

(And thx for the wontfix assessment of my proposed enhancement; I'd like to think too there's nothing to fix about it ... )

[raimue (Rainer Müller)]

Duplicate of #52000.