Paul Eggert wrote: > > I would add a placeholder for the old module name, > > for a period of transition. ... > > In the past, we've often avoided such placeholders, as Gnulib is a > source-code > module and people can upgrade at their leisure.
I disagree with the "can upgrade at their leisure" statement: * Suppose a package that uses gnulib needs to upgrade to the newest gnulib, urgently before their next release, to fix (say) a problem on Android. The renameat2 change happened before it, therefore the package maintainer must deal with the implications of the renameat2 change in a hurry. That's not "smooth", and the maintainers of that package might start to curse. * More generally, an incompatible change without transition time introduces a versioning constraint: "if we use renameat2, we need gnulib < 2018-07, if we use renameatu, we need gnulib >= 2018-07". There are other versioning constraints as well, like "if we use a pre-C99 compiler, we need gnulib < 2018-03". The more versioning constraints you get, the more complex it becomes. Often a system with 5 versioning constraints is already desparate. > I'm somewhat inclined to avoid the placeholder. I agree only because 'coreutils' is the only user of 'renameat2', and Pádraig is surely aware of the issue. Bruno
