Hi, > > Renaming binaries is a big pain, it is confusing for the user, making the > > life of the maintainer > > harder, the documentations won't reflect the Debian-reality. > > > > The wording should be changed from "must" to "should": > > --- > > Two different packages should not install programs with different > > functionality but with the same filenames. > > --- > > and give more flexibility to maintainers. > > > > Or am I missing a key reason for this? > > The current policy protects maintainers and users of less popular > packages from feeling that their package is less important in Debian, > just because something else that is more popular comes along and happens > to use the same name.
In this discussion, I would like to distinguish between package names and file names for files in a package. For package names, it makes completely sense that the first package to enter the archive is entitled to have exclusive rights to the name, even though a more popular package which appears later would have the same upstream name. That helps users of less popular packages to not feel that their package is less important in Debian. If the later and more popular package will need a "name compatibility package" such as nodejs-legacy to provide the correct upstream executable name, the users of the less popular package will still not feel (I assume) that their package is less important in Debian. > The current policy means that the discussion about which package should > use the name begins on neutral ground, without prejudice against the > less popular package. By requiring that they both change their names if > agreement cannot be reached, the maintainers put on equal footing. > To my mind, this is part of our attempt to be "the universal operating > system". My take on it is that having no way to provide the executable name which users expect (with name compatibilty packages such as nodejs-legacy was) makes the operating system less "universal" in a way. Cheers, Ruben
