Re: package contents prefix issue
Jacek Krysztofik <jacek.krysztofik@gmail.com> writes:
> Out of dozens of sophisms I had to counter only one stood out as almost
> reasonable, that I cannot guarantee some package won't suddenly release
> files in name conflict with ours. My counterargument was that it cannot
> occur in stable release, and if anything, we should prefix or suffix our
> file names, not paths to avoid this improbable calamity. Of course some
> of our files cannot be moved out of /usr prefix (such as debconf
> templates), which introduces further inconsistency.
For internal packages, this only matters if the conflict is with something
you care about. If you're never going to install the other thing, and
it's an internal package, then the path conflict is irrelevant to you and
I wouldn't give it a second thought. You could declare a Conflicts if you
felt like being formally correct.
If you're releasing the packages to the public, you might have to care,
but then your users care too. If your binaries are shadowing a completely
unrelated binary in /usr/bin, that's going to cause problems for your
users just as if your package actually conflicted. Now they get different
programs depending on their PATH; that's worse than an explicit failure to
install the package. So I would keep the binaries in /usr/bin and declare
an explicit conflict.
This is exactly the same problem that Debian itself has with binaries by
the same name in /bin, /sbin, /usr/bin, or /usr/sbin, and even though such
packages are technically possible, we try pretty hard not to create them,
because the effect on users is pretty bad.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: