On Tue, Mar 30 2021, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
>> Change the default behavior on "make install" where we fallback
>> through a chain of "ln || ln -s || cp" to instead error out when we
>> can't symlink or hardlink, and not then fallback on a "cp" (or from a
>> symlink to hardlink etc.).
>>
>> The fallback behavior was introduced in 3e073dc5611 (Makefile: always
>> provide a fallback when hardlinks fail, 2008-08-25), since then we've
>> gained the ability to specify e.g. that we'd like symlinks via the
>> INSTALL_SYMLINKS setting.
>
> Hmph, I am not so sure. "Use hardlink if we can, as that would not
> consume inode, but where hardlinks cannot be used, it is OK to use
> symlink, and I do not want to waste disk blocks with cp" is probably
> one of the sensible wishes, but at least without "ln || ln -s" fallback,
> you cannot do that, no?
>
> So I would understand if there are two orthogonal knobs
>
> - the order of preference (e.g. hardlink > symlink > copy)
> - which ones are allowed (e.g. "no symlinks please")
>
> but I cannot quite imagine how a system without any fallback would
> be useful.
Because with explicit knobs I'd like to tell it what to do and not have
it auto-guess. E.g. if I say I want openssl I don't want it to see it's
not there and auto-fallback on gnutls or whatever.
The same for "I want hardlinks/symlinks", usually someone picking one is
building a package, and under a lot of packaging formats that difference
really matters, and either won't be notinced in time or will break
further down the chain.
>> +main_no_fallbacks () {
>> + if test -n "$no_install_hardlinks" -a -z "$install_symlinks"
>
> As the values of these variables are (presumably) tightly under our
> control, the use of -a/-o with test may be safe in these examples,
> but to avoid letting clueless shell script newbies to cargo cult
> this code, let's use the safer "test -n A && test -z B" form.
*nod*
