Paul Wise <p...@debian.org> writes: > On Tue, Nov 15, 2011 at 8:14 AM, Alex Pennace wrote: > >> Even without that point, the conclusion remains the same: Both >> projects should endure the rename (unless one concedes), and that >> shouldn't be viewed in terms of "look at what those meanies in Debian >> are making us do" but instead regarded as a natural outcome of the >> choices each project made at various times. > > I personally wonder if we should change our policy instead of forcing > these two upstream communities into conflict.
In that case, I'll consider un-deprecating dpatch, and since it can very well be used outside of Debian, rename it to patch. Looking at our reverse deps and build-deps, as far as build-deps are concerned, the patch and dpatch camp is farily equal (937 vs 764), which is a much much smaller difference than in the node-vs-nodejs case, so I'll be looking forward to having patch renamed to patch.gnu or similar. (FYI, I'm a reasonablye person, so as long as patch gets renamed, I'll be content with my patch being patch.dpatch, and I'm willing to bear the consequences of having to adapt all scripts that use the old name, to use the new one.) </sarcasm> Just because two upstreams can't agree, and both choose a name far too generic, we shouldn't make our policies more forgiving to such sillyness. Furthermore, packages in Debian are - to the best of my knowledge - adapted already to use /usr/bin/nodejs, packages outside can still work unmodified, if the user makes a simple symlink. Document this, and all's well. Perhaps this will stop another upstream from choosing a similarly generic name. In all honesty, I fail to see the harm done, apart from some very minor inconvenience, which can be trivially worked around. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkfxihgh.fsf@algernon.balabit
