On Tue, Feb 14, 2017 at 02:34:38PM -0700, Jonathan Corbet wrote: > On Mon, 23 Jan 2017 08:34:58 -0200 > Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxxx> wrote: > > > The main difference between a "pointer file" and a symlink is that the > > first indicates a temporary solution, teaching people that the > > file got renamed and were it is located now. As such, we can remove > > those "pointer files" on some future Kernel releases without much concern. > > > > A symlink indicates a more permanent situation, as people will keep > > using the symlinked files as before. That means that any attempt to > > remove those in the future will generate concerns. > > > > So, I'm in favor of using the "pointer files" instead, as it > > gives us an easier way to get rid of them when we find convenient. > > So you've all long since forgotten this discussion, I'm sure, but I've > been pondering it on and off for quite a while. > > The movement of some of the more well-known documents has been a concern > of mine from the beginning; that is why I delayed those changes for > a cycle and raised the issue at a number of conferences, culminating in > the kernel summit in November. I got a strong sense of consensus that we > should go ahead and move the files. > > As Mauro says, symlinks are forever; they say we'll never really succeed > in rationalizing the structure of Documentation/. But we don't nail down > the location of any other files in the kernel source tree in this manner, > and my own feeling is that we shouldn't do that here either. The kernel > source tree is not an API. So my thinking at the moment is that we should > retain the current "pointer files" in the vague hope that, someday, we > won't need them anymore. It's a tricky balance, but I think your stance is reasonable and seems to reflect overall consensus (which might chance, we'll see). +1 from my side. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
