On 09/08/2018 08:18 PM, Sylvestre Ledru wrote: > Hello, > > Le 08/09/2018 à 18:39, Sean Whitton a écrit : >> Hello, >> >> On Fri 07 Sep 2018 at 10:10PM +0200, Ruben Undheim wrote: >> >>> However, I think the policy gives us a lot of freedom to choose (it is not >>> very >>> strict in this case). >> >> I don't understand. This seems pretty strict: >> >> Two different packages must not install programs with different >> functionality but with the same filenames. >> > I think the policy should be changed. > It was possible to accommodate that when the archive was a few thousand > packages. > Now that it is much bigger, that floss are everywhere, packages are being > forked, > we might want to update the policy to give more flexibility.
If by more flexibility, you mean allowing packages to conflict, I'm all against it. I would loose trust in Debian. By the way, forks aren't a problem, it means both packages provides the same functionality. > For example, in the Rust team, we have been discussing about packaging fd (a > find alternative developed using rust [1]). > We are planning to install it in /usr/bin/fd .. but this conflicts with > something completely different, fdclone a clone > of fd, a MS-DOS file browser... fdclone isn't a shell utility, you just start it once, then you use its ncurse-like interface. Renaming it /usr/bin/fdclone wouldn't be a problem at all, and would be useful if you need to use /usr/bin/fd, which may be useful in shell scripts (which means you need a specific name so that examples one may find online can work in Debian). > 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. I really prefer this over allowing file collisions. Cheers, Thomas Goirand (zigo)
