Re: Two groups of users, one distro in the middle
Paul Wise <email@example.com> 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.)
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
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
Perhaps this will stop another upstream from choosing a similarly
In all honesty, I fail to see the harm done, apart from some very minor
inconvenience, which can be trivially worked around.