Debian Policy 4.7.2.0 released

[Charles Plessy]

Packages that already install programs to /usr/games, where another
package installs a program of the same with different functionality
to a different directory on the default PATH, may continue to do so.

Hi Sean,

I would like to know why this exemption is only given to games? We have
scientific software that have been installing conflicting binaries for
more than one decade without any of their users complaining about it,
and I do not understand why it becomes a priority to change them now.

(I am not questionning the value of having a cleaner namespace, I am
just pointing to the fact doing such improvement will be at the expense
of doing other improvements, since our time is limited).

I also wonder if the cost of this policy will increase with time given
that a) the number of existing software is increasing, b) the number of
Debian packages is increasing, c) upstreams care less and less about
co-instability because of containers, conda namespaces etc.

Importantly, each time we rename a binary, we become incompatible with
third-party scripts, upstream documentation, *overflow advices and LLM
outputs that summarise the whole of that.

Have a nice day,

Charles

[Andrey Rakhmatullin]

Post by Charles Plessy

Packages that already install programs to /usr/games, where another
package installs a program of the same with different functionality
to a different directory on the default PATH, may continue to do so.

Hi Sean,
I would like to know why this exemption is only given to games? We have
scientific software that have been installing conflicting binaries for
more than one decade without any of their users complaining about it,
and I do not understand why it becomes a priority to change them now.

Are they installing them into different directories? That would be
surprising to me.

Post by Charles Plessy
(I am not questionning the value of having a cleaner namespace, I am
just pointing to the fact doing such improvement will be at the expense
of doing other improvements, since our time is limited).
I also wonder if the cost of this policy will increase with time given
that a) the number of existing software is increasing, b) the number of
Debian packages is increasing, c) upstreams care less and less about
co-instability because of containers, conda namespaces etc.
Importantly, each time we rename a binary, we become incompatible with
third-party scripts, upstream documentation, *overflow advices and LLM
outputs that summarise the whole of that.

All of this applies to the old version of the Policy.

[Chris Hofstaedtler]

Post by Charles Plessy

Packages that already install programs to /usr/games, where another
package installs a program of the same with different functionality
to a different directory on the default PATH, may continue to do so.

I would like to know why this exemption is only given to games? We have
scientific software that have been installing conflicting binaries for
more than one decade without any of their users complaining about it,
and I do not understand why it becomes a priority to change them now.

Please provide real examples of science packages and numbers of
affected science packages that were affected by this change.

Chris

[Sean Whitton]

Hello,

Post by Charles Plessy

Packages that already install programs to /usr/games, where another
package installs a program of the same with different functionality
to a different directory on the default PATH, may continue to do so.

Hi Sean,
I would like to know why this exemption is only given to games? We have
scientific software that have been installing conflicting binaries for
more than one decade without any of their users complaining about it,
and I do not understand why it becomes a priority to change them now.

I didn't know about this. Please share some examples on debian-***@lists.d.o.