Hi all, I think that we are asking the impossible, to be universal, cover a large number of fields, and fit all of this in a single name space witout conflicts.
With our current approach, to rename at least one of the program names, we make Debian systems incompatible with outside documentation and scripts, and one of the drawbacks of this approach is that there is no easy way to mechanically discover and report to the user which programs have been renamed compared to their original upstream distribution. If we would tolerate conflicts, we would not support the parallel use of some of our packages, but there would be the benefit that the package dependancy graph could be parsed to report clusters of mutually-incompatible packages. Often, these incompatibilities will not correspond to use cases, as there is an obvious selection pressure upstream to avoid conflicts with other programs that are directlyqused in combination with the upstream work. A third solution is possible (and of course requires work), it would be to implement namespaces in a similar way to the alternative system. Packages competing for a program name would have the original upstream name in one namespace, and leave it to the other package(s) in other namespaces. Lastly, I just read Fedora's page about packaging conflicts, and noted that among the recommendations, there is a suggestion to coordinate with the other distributions in case of renaming. http://fedoraproject.org/wiki/Packaging:Conflicts#Approaching_Upstream Perhaps it would be usefult to see what they would think of renaming the ham radio 'node' (it looks like currently the renamed program is the one of the draft node.js package). https://bugzilla.redhat.com/show_bug.cgi?id=815018 Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20120503034742.gd20...@falafel.plessy.net
