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*