build: check for ln --relative

[yann-morin-1998]

ln --relative is recent enough that not all distributions support it.
This is especially the case for enterprise-grade distributions than can
have a life-span of more than a decade.

Detect if ln supports --relative and use it if so.

If not supported, use a bit of sed magic to construct the ../ sequence,
that leads back to / when appended to the destination directory.

We introduce this as a macro that expands to a single command. To avoid
complexity in the macro, we expect paths to be passed whitout the
leading DESTDIR.

[evverx]

not all distributions support it

What distributions don't support it?

ln --relative is recent enough

--relative has been available since 22 Mar 2012. Please note that building v233 requires at least gperf 3.1, which was released on January 5, 2017.

[evverx]

I think this should be patched somewhere downstream.

[yann-morin-1998]

@evverx

1. RHEL5, released in 2007, extended support up to 2021; RHEL6, released in 2010, supported until 2021; [0]
2. we were not aware of the gperf requirement, as the build was fine with gperf 3.0.4;
3. we can build gperf (it takes ~3s) but building a coreutils just for ln that supports --relative is a relatively high price to pay (1min);
4. what do you mean by "should be patched somewhere downstream"? Do you mean that distributors (debian, RH, FC...) or buildsystems (buildroot, openwrt, yocto...) should patch it away?
5. you marked the PR "changes requested"; what kind of changes do you need?

Thanks for the review and comments! :-)

[0] we in Buildroot try to support building on enterprise-grade distributions, like the RHEL series,
which are prevalent in enterprise setups, and can sometimes be lagging behind in terms of versions.

[1] for example, I have a build that takes a bit les than 20 min; adding 1 min is a 5% overhead which is quite a bit noticeable, especially as it may be built a great many times a day... :-(

Regards,
Yann E. MORIN.

[evverx]

you marked the PR "changes requested"; what kind of changes do you need?

Sorry, I should have chosen "comment". I'll fix that.

what do you mean by "should be patched somewhere downstream"?

I mean that coreutils should be built as a part of a toolchain/a build dependency. Or maybe this patch should be applied to the source of systemd downstream.

I'm not sure that systemd is supposed to be built/work on those distros without heavy patching. But I could be wrong of course.

I should have chosen "comment".

[yann-morin-1998]

@evverx Thanks for the feedback.

So, yes, coreutils could be built. However, it takes a lot of time to build (see my previous reply) which can add quite a fair amount to the build time, when what we "just" need of it is ln. And no, it is not always possible to install an updated coreutils system-wide, like on a shared build farm.

As for the "old" distros: please consider that they are present in a lot of companies (for various reasons, one being long-term support, the other being reproducibility in the long term, like 10+ years). And no, I do not expect systemd to work on those distro, but they can be used to cross-compile systemd for, say, an embedded target with all latest and greatest components (kernel, gcc, systemd...). This is a typical setup.

Thanks. ;-)

Regards,
Yann E. MORIN.

[poettering]

We really don't care too much building systemd on really old distros, the same way we don't support building it against really old kernels. In fact, we are much more agressive with build deps than with runtime deps, and ln --relative is only a build dep. We try to focus on building things with kernels that are 2y old or newer, though currently we do support 3y old kernels, too. ln --relative is 5y old now, and that's an eternity in IT. Hence I fully agree with @evverx: this is beyond what we intend to support upstream.

Please update your local system, I am pretty sure focussing on 5y old infrastructure is not even a safe thing to do these days. Alternatively, maintain this patch downstream.

Sorry if this is disappointing, but I do hope this makes sense.