Hi

I'm doing archive-wide package rebuilds in GitLab CI/CD and my toolchain
uses 'setpriv --reset-env' to drop privileges and reset the environment variables, which results in:

PATH=/usr/local/bin:/bin:/usr/bin

This unusual ordering appears to be intentional for setpriv:

https://manpages.debian.org/bookworm/util-linux/setpriv.1.en.html

However this ordering is different than the PATH used on buildd's:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Having /bin before /usr/bin cause FTBFS of some packages. The most
simple example is packages that invoke gradle. It appears to happen
both on bookworm and trixie, and is easy to reproduce:

podman run -it --rm debian:trixie
apt-get update
apt-get install -y --no-install-recommends gradle PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
gradle
/bin/gradle: 23: cd: can't cd to /bin/../share/gradle/bin/..

The problem seems that it is generating a relative path to its own
command expanded via PATH, which doesn't work because there is no /share symlink but there is /usr/share/.

Is this a problem in 'gradle' (and other packages) that should be
reported and fixed? What severity?

What can packages assume about PATH? What can packages not assume? In particular wrt ordering. Are there written down rules for this?

Here is one example build log, if you want to see the error in action
during a package build: https://gitlab.com/debdistutils/build/debian-bookworm-arm64-20250407-stage0/-/jobs/9927466433

/Simon

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmgZ17cUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFor4CAQDbbiaOTeUr qZAo746+XO2wdW50GGEUFPpn3PPIeYbVqgD/Xqf4B2l7gvERRaWLwmBJohsK1EGk ctCHa2INdeI4tgs=
=lC2o
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Simon Josefsson <[email protected]> [250506 11:35]:

I'm doing archive-wide package rebuilds in GitLab CI/CD and my toolchain
uses 'setpriv --reset-env' to drop privileges and reset the environment >variables, which results in:

PATH=/usr/local/bin:/bin:/usr/bin

This unusual ordering appears to be intentional for setpriv:

https://manpages.debian.org/bookworm/util-linux/setpriv.1.en.html

However this ordering is different than the PATH used on buildd's:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Having /bin before /usr/bin cause FTBFS of some packages. The most
simple example is packages that invoke gradle. It appears to happen
both on bookworm and trixie, and is easy to reproduce:

podman run -it --rm debian:trixie
apt-get update
apt-get install -y --no-install-recommends gradle >PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
gradle
/bin/gradle: 23: cd: can't cd to /bin/../share/gradle/bin/..

I'll point out that this is not even trying to build a Debian
package, so the typical Debian package build environment would be
irrelevant here.

The problem seems that it is generating a relative path to its own
command expanded via PATH, which doesn't work because there is no /share >symlink but there is /usr/share/.

Is this a problem in 'gradle' (and other packages) that should be
reported and fixed?

IMO yes, see below.

What severity?

normal?

What can packages assume about PATH? What can packages not assume? In >particular wrt ordering. Are there written down rules for this?

Probably in POSIX. Per my understanding PATH is defined to be used
in a specific algorithm, which is basically "stat the name of the
executable you are looking for in these directories, in the given order".

Everything else is probably unspecified, and deriving file system
paths that are not actually given in PATH is undefined behaviour,
and can just break.

If a program needs to know a path to supporting files, this path
should be known at build time of that program (here: gradle), and
then be baked into it (and maybe also be configurable at runtime).

Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Quoting Simon Josefsson (2025-05-06 11:34:47)

The problem seems that it is generating a relative path to its own command expanded via PATH, which doesn't work because there is no /share symlink but there is /usr/share/.

Is this a problem in 'gradle' (and other packages) that should be
reported and fixed? What severity?

What can packages assume about PATH? What can packages not assume? In particular wrt ordering. Are there written down rules for this?

I think you can reformulate this problem a bit differently. Instead of saying "is it a problem to shuffle PATH order" you could also ask "should it be a problem whether a program is invoked from either their aliased or unaliased location?"

With the finalization of /usr-merge, many programs were moved from /bin into their unaliased location under /usr/bin also with the argument: if programs rely on it to exist in /bin then that is still the case even after moving the actual path due to the top-level symlink. What you have here is an instance where a program is intended to never be called from their unaliased path or otherwise it cannot find /usr/share.

My gut feeling is that software that does this should be made robust in finding /usr/share independent of from where it is called.

Thanks!

cheers, josch
--==============$86086323454161387=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmgZ5ykACgkQ8sulx4+9 g+G6kw//TMqh4sClR5W4rYYsxy64NY92Z9OL7sr8ZAQp6C9K3WaAE+1KPM64sfDs 1BO3xAd1QyKbmr6/ACnDVkDts9kIYxUKLxOU3iS62SHz+/dodGYf5SwdhFWjIx/b 586eXhoEXPXHl5CXP8YW+BVQyiJH/muM3nAtiA4QxhU20lFozOQWXeyzZP399dko Y/kTRq9AEi/Jnye05l/LuZ8pbIKpZzJnnwqiHjgS3Br6QVEHEQ147+JplciI0l25 iQVxwhbXCP8CsdkPWNXcJrKpueyyq/wrlhyoTRCON8HLOs4xc2miPq+BtlwOl21J qddX9oRsJOU8ZZ3OSIaIbKrtqG8Tc6Eb0oSHWHcnjLpflRKFHy0uPdD6r3Qne5Ok GyZyn7J0I8Ek+SsUSfyYPqSPQngTmKY4mxtXfyc+Qfbi/7p8vQ98wCFZBCOm3G4b rH0X8KWH96+U+p9ppoo1AxVmJtDLC7K2/3CxHsQWzGccTtd3ZeXEh6opZO5Khx27 PZkwKGIkJSAAYwWezaKwj9mhxekoJHg4Rdl3SWTVjOca0Xupmfp2TGBeuGszeMRX XEkzX3w4ECIdiPlthg4omLHFzEdVT1V6HyGu7OCzBcfoUdHhxqnHBXMXhaPmfO8c iUi4R8pDCWOv9Mwgd5j1SkV5jTiGog8CV88w0f1RoY9MX40Q1fY=
=RHvx
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/05/2025 10:34, Simon Josefsson wrote:

podman run -it --rm debian:trixie
apt-get update
apt-get install -y --no-install-recommends gradle PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
gradle
/bin/gradle: 23: cd: can't cd to /bin/../share/gradle/bin/..

The problem seems that it is generating a relative path to its own
command expanded via PATH, which doesn't work because there is no /share symlink but there is /usr/share/.

Perfectly reasonable method to support installing to /usr, /usr/local, $HOME/.local, ...

Is this a problem in 'gradle' (and other packages) that should be
reported and fixed? What severity?

I would view it as a missing feature in setpriv to set an env var.
Fedora doesn't set /bin anymore in the $PATH and trying to unify
/usr/bin and /usr/sbin.
setpriv should probably accommodate that since debian and Fedora behave differently. Even openwrt routers prefer /usr/bin.

What can packages assume about PATH? What can packages not assume? In particular wrt ordering. Are there written down rules for this?

Assume more local entries first ($HOME/.local/X, then /usr/local/X),
then /usr/X preferred. /X is fallback only.
Cannot assume "argv[0] == /usr/bin/X" or base is /usr in general.
Not sure if that helped.


--
Regards,
Ahmad

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Johannes Schauer Marin Rodrigues <[email protected]> writes:

Hi,

Quoting Simon Josefsson (2025-05-06 11:34:47)

The problem seems that it is generating a relative path to its own command >> expanded via PATH, which doesn't work because there is no /share symlink but >> there is /usr/share/.

Is this a problem in 'gradle' (and other packages) that should be
reported and fixed? What severity?

What can packages assume about PATH? What can packages not assume? In
particular wrt ordering. Are there written down rules for this?

I think you can reformulate this problem a bit differently. Instead of saying "is it a problem to shuffle PATH order" you could also ask "should it be a problem whether a program is invoked from either their aliased or unaliased location?"

With the finalization of /usr-merge, many programs were moved from /bin into their unaliased location under /usr/bin also with the argument: if programs rely on it to exist in /bin then that is still the case even after moving the actual path due to the top-level symlink. What you have here is an instance where a program is intended to never be called from their unaliased path or otherwise it cannot find /usr/share.

Agreed.

My gut feeling is that software that does this should be made robust in finding
/usr/share independent of from where it is called.

Yes, I think that seems reasonable. I opened this one:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104784

There are packages that invoke Gradle during package builds that will
FTBFS until that bug is fixed. I've already changed my build system to
use PATH=/usr/bin only so I'm not sure it is worth spending cycles
trying to find all affected packages. I mention some bookworm packages
that FTBFS with this PATH setting in the bug report.

Should the Debian Policy or Developers Reference should say something
about expectations about the PATH variable value though? I wonder how
many packages FTBFS if PATH is set to a "weird" value like PATH=/foo\ bar/foo!bar:$PATH.

/Simon

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmgaG6kUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFovCqAQCGyMZDzoX+ rNaHxPXLolczbtOv3tMxcrukcUsTJNhUIgEA22BooWYoqCLf4j0HxTlLikKCz/00 xmEU6PWwdYbmZAI=BwrO
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chris Hofstaedtler <[email protected]> writes:

podman run -it --rm debian:trixie
apt-get update
apt-get install -y --no-install-recommends gradle >>PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
gradle
/bin/gradle: 23: cd: can't cd to /bin/../share/gradle/bin/..

I'll point out that this is not even trying to build a Debian package,
so the typical Debian package build environment would be irrelevant
here.

Right, I was just giving a way to reproduce the problem. Packages that
rely on 'gradle' during build will fail with that error message too,
when built with a PATH that has /bin before /usr/bin.

The problem seems that it is generating a relative path to its own
command expanded via PATH, which doesn't work because there is no /share >>symlink but there is /usr/share/.

Is this a problem in 'gradle' (and other packages) that should be
reported and fixed?

IMO yes, see below.

What severity?

normal?

Thanks -- I opened
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104784

What can packages assume about PATH? What can packages not assume? In >>particular wrt ordering. Are there written down rules for this?

Probably in POSIX. Per my understanding PATH is defined to be used in
a specific algorithm, which is basically "stat the name of the
executable you are looking for in these directories, in the given
order". Everything else is probably unspecified, and deriving file
system paths that are not actually given in PATH is undefined
behaviour, and can just break.

I think there could be a Debian policy that says that packages MUST NOT
assume anything about PATH except that it should somewhere include
/usr/bin (and maybe also /usr/games) during build. It seems common in
Debian to add /*/sbin too, but when building as non-root, I don't think
/*/sbin should be part of PATH and packages shouldn't assume this.

If a program needs to know a path to supporting files, this path
should be known at build time of that program (here: gradle), and then
be baked into it (and maybe also be configurable at runtime).

Agreed.

/Simon

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmgaHLYUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFotQ+AQCdeNwwkfmF RzUQ2YuuGts9hy2Jvqa5FXxoNcGp8bkwKAD+KjlAfWwftjTdisgwNUzUEzXKBhll b/QmcxR8QsX/BgY=
=vqtP
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 5/6/25 20:31, Ahmad Khalifa wrote:

The problem seems that it is generating a relative path to its own
command expanded via PATH, which doesn't work because there is no /share
symlink but there is /usr/share/.

Perfectly reasonable method to support installing to /usr, /usr/local, $HOME/.local, ...

I disagree. These paths should be taken from configure arguments and
compiled in, because distributions may change the layout of the package
-- e.g. dlopen()ing a shared library requires looking into the
multi-arch directory, and configuration files for packages in /usr are routinely found in /etc, while configuration files for manually
installed packages below /usr/local can be in /usr/local/etc as well.

Hardcoding relative paths is going to be brittle, especially if the configuration system allows deviating from the default layout, and the
amount of hackery required to make both work together is not worth it.

Simon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------XNEYWk8NEEV020rvWcmeMgGg
Content-Type: multipart/mixed; boundary="------------K35ViVQHioksJGgu28pNJcPZ"

--------------K35ViVQHioksJGgu28pNJcPZ
Content-Type: multipart/alternative;
boundary="------------H47Ia4nNzA1obEvAnMxxCY4T"

--------------H47Ia4nNzA1obEvAnMxxCY4T
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMDYuMDUuMjUgMTM6MzEsIEFobWFkIEtoYWxpZmEgd3JvdGU6DQo+IEZlZG9yYSBkb2Vz bid0IHNldCAvYmluIGFueW1vcmUgaW4gdGhlICRQQVRIDQoNCklNSE8gd2Ugc2hvdWxkIGZv bGxvdyB0aGF0IHByYWN0aWNlLCBwb3N0LVRyaXhpZS4NCg0KLS0gDQotLSByZWdhcmRzDQot LSANCi0tIE1hdHRoaWFzIFVybGljaHMNCg0K
--------------H47Ia4nNzA1obEvAnMxxCY4T
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 06.05.25 13:31, Ahmad Khalifa wrote:<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">Fedora
doesn't set /bin anymore in the $PATH</blockquote>
<p>IMHO we should follow that practice, post-Trixie.<br>
</p>
<pre class="moz-signature" cols="72">--
-- regards
--
-- Matthias Urlichs</pre>
</body>
</html>

--------------H47Ia4nNzA1obEvAnMxxCY4T--

--------------K35ViVQHioksJGgu28pNJcPZ
Content-Type: text/vcard; charset=UTF-8; name="matthias.vcf" Content-Disposition: attachment; filename="matthias.vcf" Content-Transfer-Encoding: base64

QkVHSU46VkNBUkQNClZFUlNJT046NC4wDQpOOlVybGljaHM7TWF0dGhpYXM7OzsNCk5JQ0tO QU1FOlNtdXJmDQpFTUFJTDtQUkVGPTE6bWF0dGhpYXNAdXJsaWNocy5kZQ0KVEVMO1RZUEU9 d29yaztWQUxVRT1URVhUOis0OSA5MTEgNTk4MTggMA0KVVJMO1RZUEU9aG9tZTpodHRwczov L21hdHRoaWFzLnVybGljaHMuZGUNCkVORDpWQ0FSRA0K

--------------K35ViVQHioksJGgu28pNJcPZ--

--------------XNEYWk8NEEV020rvWcmeMgGg--

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEr9eXgvO67AILKKGfcs+OXiW0wpMFAmgbHEAFAwAAAAAACgkQcs+OXiW0wpMC WA/+Ol2CsTqqhzaic9x77f2IRqMwdMoZ6e3K14er0apK0F9/8zkZaeNTbdi+ZBmpzXbzWrRaT8fl rG4ICaNqGbjV1ULksh1Aq8S2cSFk0y9q3S3r/rxZ81UlffNg+3rmLgsf+J7CmN4gRPvvrFbbFLkg 6HN0t+GIrW/NA2VXV9M1wHwSAOLaW95wtX1Tw+v5dD70XcgIm4vTaLYlul5D0kk6GzAqwXFVzj6F 3aVKtkUO0luzg75oOQAJP0IZA+

On 2025-05-06 12:31:08 +0100, Ahmad Khalifa wrote:

On 06/05/2025 10:34, Simon Josefsson wrote:

podman run -it --rm debian:trixie
apt-get update
apt-get install -y --no-install-recommends gradle PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
gradle
/bin/gradle: 23: cd: can't cd to /bin/../share/gradle/bin/..

The problem seems that it is generating a relative path to its own
command expanded via PATH, which doesn't work because there is no /share symlink but there is /usr/share/.

Perfectly reasonable method to support installing to /usr, /usr/local, $HOME/.local, ...

No, the end user should be able to use symlinks from his $HOME/bin
to resolve conflicts for commands with the same name, e.g. due to
3rd-party commands in /usr/local/bin.

--
Vincent Lef�vre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Matthias Urlichs <[email protected]> writes:

On 06.05.25 13:31, Ahmad Khalifa wrote:

Fedora doesn't set /bin anymore in the $PATH

IMHO we should follow that practice, post-Trixie.

Agreed. I wrote a bug report about that and then found it was already reported, so summarizing:

1) login.defs can drop /bin and /sbin from its default PATH: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041362

2) Setpriv could be amended to support login.defs: https://github.com/util-linux/util-linux/issues/3560

3) I think 'gradle' failing on PATH=/bin:$PATH is buggy and should be
fixed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104784

4) The policy manual or developers reference could be amended to say
that packages MUST only assume that /usr/bin and /usr/games (+ /usr/sbin
for su/root) are in PATH and MUST handle being invoked as another alias.

/Simon

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmgbJqsUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFoqKyAQCOCmEVDuJf yjAFq/x9o/MwLbJYDIGsQb/e+fuiPMzs1QEA+mvRpfG9hXwGvOAwE9ZPjH/ommQV Hl3g4ek/RUZN/A0=
=I9Io
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 7/5/25 a las 10:39, Matthias Urlichs escribió:

On 06.05.25 13:31, Ahmad Khalifa wrote:

Fedora doesn't set /bin anymore in the $PATH

IMHO we should follow that practice, post-Trixie.

I disagree that we should do that.

AFAIK, the usr-merge was not about moving everything to usr/bin (that's an implementation detail) but about making /bin and /usr/bin equivalent.

So, while we could in theory drop /bin, doing so might involve undesired
side effects. For example, some configure script might look in
the PATH and decide that sh is in /usr/bin and ship shell scripts
as #!/usr/bin/sh. Sure, this will work for Debian stable, but it breaks backwards compatibility without a real need to do so. AFAIK, the aim
of usr-merge was not to break compatibility, but quite the opposite.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Santiago Vila <[email protected]> writes:

El 7/5/25 a las 10:39, Matthias Urlichs escribi�:

On 06.05.25 13:31, Ahmad Khalifa wrote:

Fedora doesn't set /bin anymore in the $PATH

IMHO we should follow that practice, post-Trixie.

I disagree that we should do that.

AFAIK, the usr-merge was not about moving everything to usr/bin (that's an implementation detail) but about making /bin and /usr/bin equivalent.

So, while we could in theory drop /bin, doing so might involve undesired
side effects.

I think we need to separate:

1) Removing /bin from the default PATH environment variable.

2) Removing the /bin symlink.

To clarify, are you against both or just one of these?

I hadn't thought about 2) but what you write sounds more like you are
thinking of 2) than 1) which was where the discussion started.

For example, some configure script might look in the PATH and decide
that sh is in /usr/bin and ship shell scripts as #!/usr/bin/sh.

Right. I'm not sure solving that problem by adding /bin to PATH before /usr/bin is the best long-term solution, though. Guix has shown that
the only hard-coded path that is required is /bin/sh and I think that is
a good model and that all upstream projects should work in that model by default. So I'd prefer if such problems were fixed upstream, rather
then Debian adopting workarounds.

I don't care strongly about the solution here, I just find that the
'gradle' behaviour buggy and the 'setpriv --reset-env' default PATH
value surprising. Both of these issues can be resolved without doing
anything about /etc/login.defs PATH, but it seems we may also think
about /etc/login.defs changes too, because the gradle/setpriv problems
wouldn't have happened if 1) and/or 2) above was implemented.

/Simon

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmgbRsQUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFouKjAQCIjtfKqG+7 QGuEMTcjQm0qT6EYvPc94LKzMKBZG5KGfQD8CLQaQleyEaks/E00e3Y1KYGSECbl XNOBvoFhcRiqZw0�c+
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------YqeQYRlBlWeTigB2LVMzl0dm
Content-Type: multipart/mixed; boundary="------------T8xoHHE7HfsNymwvTQY8DX8B"

--------------T8xoHHE7HfsNymwvTQY8DX8B
Content-Type: multipart/alternative;
boundary="------------62mIW1iBvcqdaTLK3yCcB8We"

--------------62mIW1iBvcqdaTLK3yCcB8We
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMDcuMDUuMjUgMTI6MDAsIFNhbnRpYWdvIFZpbGEgd3JvdGU6DQo+IEZvciBleGFtcGxl LCBzb21lIGNvbmZpZ3VyZSBzY3JpcHQgbWlnaHQgbG9vayBpbg0KPiB0aGUgUEFUSCBhbmQg ZGVjaWRlIHRoYXQgc2ggaXMgaW4gL3Vzci9iaW4gYW5kIHNoaXAgc2hlbGwgc2NyaXB0cw0K PiBhcyAjIS91c3IvYmluL3NoLg0KDQpUaGF0J3Mgbm90IGEgcHJvYmxlbSwgYmVjYXVzZSB0 b2RheSdzIGRlZmF1bHQgKGFjY29yZGluZyB0byBteSANCi9ldGMvbG9naW4uZGVmcykgaXMg Ii91c3IvbG9jYWwvYmluOi91c3IvYmluOi9iaW4iIChwbHVzIC9zYmluIGZvciByb290LCAN CnBsdXMg4oCmL2dhbWVzIGZvciBub24tcm9vdCksIGkuZS4gd2l0aCB0aGUgc3ltbGlua3Mg bGFzdC4NCg0KVGh1cywgaWYgYW55dGhpbmcgZG9lcyBkbyB0aGlzIGl0J2xsIGdvIHNwbGF0 IHdoZXRoZXIgb3Igbm90IHdlIHJlbW92ZSANCiI6L2JpbiIgZnJvbSBvdXIgUEFUSC4NCg0K LS0gDQotLSBtaXQgZnJldW5kbGljaGVuIEdyw7zDn2VuDQotLSANCi0tIE1hdHRoaWFzIFVy bGljaHMNCg0K
--------------62mIW1iBvcqdaTLK3yCcB8We
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 07.05.25 12:00, Santiago Vila wrote:<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">For
example, some configure script might look in
<br>
the PATH and decide that sh is in /usr/bin and ship shell scripts
<br>
as #!/usr/bin/sh.</blockquote>
<p>That's not a problem, because today's default (according to my
/etc/login.defs) is "/usr/local/bin:/usr/bin:/bin" (plus /sbin for
root, plus …/games for non-root), i.e. with the symlinks last.</p>
<p>Thus, if anything does do this it'll go splat whether or not we
remove ":/bin" from our PATH.<br>
</p>
<pre class="moz-signature" cols="72">--
-- mit freundlichen Grüßen
--
-- Matthias Urlichs</pre>
</body>
</html>

--------------62mIW1iBvcqdaTLK3yCcB8We--

--------------T8xoHHE7HfsNymwvTQY8DX8B
Content-Type: text/vcard; charset=UTF-8; name="matthias.vcf" Content-Disposition: attachment; filename="matthias.vcf" Content-Transfer-Encoding: base64

QkVHSU46VkNBUkQNClZFUlNJT046NC4wDQpOOlVybGljaHM7TWF0dGhpYXM7OzsNCk5JQ0tO QU1FOlNtdXJmDQpFTUFJTDtQUkVGPTE6bWF0dGhpYXNAdXJsaWNocy5kZQ0KVEVMO1RZUEU9 d29yaztWQUxVRT1URVhUOis0OSA5MTEgNTk4MTggMA0KVVJMO1RZUEU9aG9tZTpodHRwczov L21hdHRoaWFzLnVybGljaHMuZGUNCkVORDpWQ0FSRA0K

--------------T8xoHHE7HfsNymwvTQY8DX8B--

--------------YqeQYRlBlWeTigB2LVMzl0dm--

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEr9eXgvO67AILKKGfcs+OXiW0wpMFAmgbS8gFAwAAAAAACgkQcs+OXiW0wpOC 9hAAj8tniUB8AVqkVkW6avxuT1TOTVKoVr/5wtq3CT9+/z6DvguHVJT6TsFDxDxW16XKHCnUvqRs XCaONysq/OqNHILwWwnZxVxFFhU0DdSDfKROT/RYy5otXfivvQITUfJXhtD46LGKnZA63rTpG6Cl GzSqroqd0FbhtLTT5fcRuHkCPR6QjIdw3HtoYmY2glt5YrWlVzBwobtaAA5cw2/4e+kyRt1lD1+J 1Yc1ka6YTrWtj0xxaYTz0w4ZJz

Matthias Urlichs <[email protected]> writes:

On 07.05.25 12:00, Santiago Vila wrote:

For example, some configure script might look in
the PATH and decide that sh is in /usr/bin and ship shell scripts
as #!/usr/bin/sh.

That's not a problem, because today's default (according to my /etc/login.defs) is "/usr/local/bin:/usr/bin:/bin" (plus /sbin for
root, plus …/games for non-root), i.e. with the symlinks last.

One problem is that there is no policy on what PATH can or should be
when building a Debian package, or is there?

So if some package build system (like mine) uses 'setpriv' to drop
privileges they will get /bin before /usr/bin, and in this situation
Santiago's concerns apply.

I think a reasonable conservative system policy is PATH=/usr/bin and
anything beyond that is something the user or system administrator have
to add. I think we should give up on /usr/games and move those
executables to /usr/bin, renaming any binaries that conflict.

/Simon

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmgbVKEUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFojctAP9+54QbjYLQ HISKNtARpGxCiyCph9AeU0UMDGEVbVyq9wD+LT/lVAquMNeNk0AB9vEgl8OShqEO Txj2qIQUlTkQMgE=zuIC
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-07 14:02:15 +0200, Matthias Urlichs wrote:

That's not a problem, because today's default (according to my /etc/login.defs) is "/usr/local/bin:/usr/bin:/bin" (plus /sbin for root,
plus …/games for non-root), i.e. with the symlinks last.

Note that commands may be run via other ways than a login shell.
For instance, /etc/anacrontab has

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

This is not consistent with the /etc/login.defs PATH.

--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 7/5/25 a las 13:40, Simon Josefsson escribió:

Santiago Vila <[email protected]> writes:

El 7/5/25 a las 10:39, Matthias Urlichs escribió:

On 06.05.25 13:31, Ahmad Khalifa wrote:

Fedora doesn't set /bin anymore in the $PATH

IMHO we should follow that practice, post-Trixie.

I disagree that we should do that.

AFAIK, the usr-merge was not about moving everything to usr/bin (that's an >> implementation detail) but about making /bin and /usr/bin equivalent.

So, while we could in theory drop /bin, doing so might involve undesired
side effects.

I think we need to separate:

1) Removing /bin from the default PATH environment variable.

2) Removing the /bin symlink.

To clarify, are you against both or just one of these?

Sorry for the confusion, I meant "drop /bin from the PATH".
(I don't think anybody is proposing 2) right now).

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-07 14:40:01 +0200, Simon Josefsson wrote:

I think a reasonable conservative system policy is PATH=/usr/bin and
anything beyond that is something the user or system administrator have
to add. I think we should give up on /usr/games and move those
executables to /usr/bin, renaming any binaries that conflict.

I disagree. root should not have games in his path. This could also
annoy non-root users.

--
Vincent Lef�vre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 07 May 2025 at 15:21:43 +0200, Santiago Vila wrote:

El 7/5/25 a las 13:40, Simon Josefsson escribi�:

I think we need to separate:

...

2) Removing the /bin symlink.

...

(I don't think anybody is proposing 2) right now).

My understanding is that the compatibility symlinks /bin, /lib* and
/sbin in the root directory can never be deleted, and even the least conservative advocates of merged-/usr don't intend to delete them,
because they are part of the platform ABI. They could be owned by
base-files, or created programmatically, or even created by tmpfiles.d,
but they have to exist. In practice the implementation we've chosen in
Debian is that base-files owns them.

(/bin for /bin/sh, which is one of the few Unix paths that are
universally available, and possibly specified by POSIX; /lib for several architectures' ld.so paths, as specified by the psABI; /lib64 for
several other architectures' ld.so paths, as specified by the psABI; and
maybe /sbin could eventually be removed but it seems like something
whose effort and risk would be a lot higher than its benefit, because we
need to keep /bin anyway, and then whatever mechanism ensures that /bin
exists can equally easily take responsibility for /sbin.)

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On May 07, Simon McVittie <[email protected]> wrote:

My understanding is that the compatibility symlinks /bin, /lib* and
/sbin in the root directory can never be deleted, and even the least >conservative advocates of merged-/usr don't intend to delete them,
because they are part of the platform ABI.

Correct.

--
ciao,
Marco

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCaBtmIwAKCRDLPsM64d7X gfQiAQDSSkZe0ew1x3OScFi8hV5ILV/uF4BwkO/oYLqG+80L0QD9Fgf7vN4pK/jJ 4eQe0z6RPuT9G0NYAeDewRH8Yxk4Jgc=
=0mAD
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07/05/2025 02:59, Simon Richter wrote:

Hi,

On 5/6/25 20:31, Ahmad Khalifa wrote:

The problem seems that it is generating a relative path to its own
command expanded via PATH, which doesn't work because there is no /share >>> symlink but there is /usr/share/.

Perfectly reasonable method to support installing to /usr, /usr/local,
$HOME/.local, ...

I disagree. These paths should be taken from configure arguments and
compiled in, because distributions may change the layout of the package
-- e.g. dlopen()ing a shared library requires looking into the multi-
arch directory, and configuration files for packages in /usr are
routinely found in /etc, while configuration files for manually
installed packages below /usr/local can be in /usr/local/etc as well.

Hardcoding relative paths is going to be brittle, especially if the configuration system allows deviating from the default layout, and the
amount of hackery required to make both work together is not worth it.

Sure, compiled-in PREFIX is better.

Scripts and interpreted languages can't always do that to find their
runtime data.

bin/ launcher symlinks, it's pretty common to rely on relative paths for
those:
$ find /usr/bin/ /usr/local/bin -type l -ls | grep ' ../' | wc -l
247

None of it is an issue if /usr/bin is higher priority.


--
Regards,
Ahmad

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

--a5f78e0f90d478ccb4f16d4e34344c03553670fb028019b06ce1b32c1a52 Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8; format=Flowed

Hi,

On Wed May 7, 2025 at 12:00 PM CEST, Santiago Vila wrote:

AFAIK, the usr-merge was not about moving everything to usr/bin
(that's an implementation detail) but about making /bin and /usr/bin equivalent.

I had the opposite impression. The goal *is* moving stuff to /usr, as
a prerequisite of the hermetic-/usr concept. Also, for bin/
specifically, having both /usr/bin and /bin does not make sense anymore.

The fact that /bin and /usr/bin became equivalent was the implementation
that Fedora originally chose, and we followed to avoid cross-distro
breakages.

This is also why alternative approaches like merged-/usr-via-moves-and-symlink-farms were proposed (ref: <https://wiki.debian.org/Teams/Dpkg/MergedUsr#merged-.2Fusr-via-moves-and-symlink-farms>)

Am I misunderstanding something?

Bye!

--a5f78e0f90d478ccb4f16d4e34344c03553670fb028019b06ce1b32c1a52
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iIcEABYKAC8WIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCaBt05REcdGFjaGlAZGVi aWFuLm9yZwAKCRBKkgiiRVB3p7U/AQDBQKKEq5G6Z0d5kztASurAvdAyvArijx5c 6W/2jHLc9AD+PWfZt9ZTCCeb4qKJkxWF5jlveKAnXvwCXNtuXgPzaww=9JIE
-----END PGP SIGNATURE-----

--a5f78e0f90d478ccb4f16d4e34344c03553670fb028019b06ce1b32c1a52--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Vincent Lefevre <[email protected]> writes:

On 2025-05-07 14:40:01 +0200, Simon Josefsson wrote:

I think a reasonable conservative system policy is PATH=/usr/bin and
anything beyond that is something the user or system administrator have
to add. I think we should give up on /usr/games and move those
executables to /usr/bin, renaming any binaries that conflict.

I disagree. root should not have games in his path. This could also
annoy non-root users.

That is a good point. Hmm. There is a lot more in /usr/bin that I
wouldn't want root to have in PATH either, so I'm not sure I agree that
the /usr/games exception gives root sufficient protection. Given that
it is permissable to have naming conflicts as in /usr/bin/foo and /usr/games/foo, I would prefer the situation where everything under
/usr/games was moved to /usr/bin and renamed on naming conflicts. Then
root doesn't have to consider the possibility that invoking 'foo' may
somehow end up running /usr/games/foo instead of /usr/bin/foo depending
on PATH confusion.

/Simon

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmgbh9EUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFom+WAQCweSYpw5Na KxKm7B8InPQuXDUjz/XN+W3x9MGx4FsX6wD/W+Og6swWdvKvF6sXSpCwIDqxArSy SVjLgGE6/1yW/gk=
=7ZPm
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 07 May 2025 at 14:40:01 +0200, Simon Josefsson wrote:

I think we should give up on /usr/games and move those
executables to /usr/bin, renaming any binaries that conflict.

This seems somewhat off-topic for a discussion of FTBFS - I hope that
packages don't assume that /usr/games is in the PATH at build time in
any case.

Whether we merge /usr/games into /usr/bin or not, I think it would be a
good improvement **for forky** (not trixie!) to revert the single change
that was made in Policy 4.7.2 (see #1098948), so that it's unambiguously
a bug to have both /usr/games/pacman (a maze traversal game) and /usr/bin/pacman (Arch's package manager) with different functionality.
I'm sure that's already on someone else's radar, with the most likely
result being /usr/games/pacman getting renamed or removed.

On Wed, 07 May 2025 at 15:45:28 +0200, Vincent Lefevre wrote:

I disagree. root should not have games in his path.

On Wed, 07 May 2025 at 18:17:49 +0200, Michael Biebl wrote:

I personally think that games aren't particularly special in any way
that would warrant them being shipped in a separate directory so I
would welcome if /usr/games became an empty directory (i.e. we move
all binaries to /usr/bin).

Considering whether to move games into /usr/bin and stop recommending /usr/games is/was #567033. I would suggest reopening that bug (perhaps
after the trixie release) if there is going to be an attempt to get
consensus on doing this. The essence of the decision to be made is whether
the risk of accidents from having these programs in root's PATH
(see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567033#119)
is a stronger or weaker consideration than the ongoing maintenance cost
of having a separate /usr/games.

(/usr/games is also the place for game-related utilities like game-data-packager, game launchers/managers like steam, and
"toys" like fortune, which are not technically games but
share many of the same considerations that I described in #567033.)

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Simon McVittie <[email protected]> writes:

On Wed, 07 May 2025 at 14:40:01 +0200, Simon Josefsson wrote:

I think we should give up on /usr/games and move those
executables to /usr/bin, renaming any binaries that conflict.

This seems somewhat off-topic for a discussion of FTBFS - I hope that packages don't assume that /usr/games is in the PATH at build time in
any case.

Is it a bug if they do? Buildd's have /usr/games in the default PATH so
I don't think we notice now.

My archive rebuild now uses PATH=/usr/bin so I will get breakage for any package that FTBFS because of missing /usr/games in PATH. If this
causes too much problems, I'll probably modify it to use PATH=/usr/bin:/usr/games unless there is some clarification if this is a
bug worth reporting.

/Simon

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmgbqc0UHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFojwMAPwPhIaguXyy 5cQAM9ac2+yZuxjjbUdrNwzyLLbRKyEZtwEAxCMi0LAbZfnp6L+tLsmU7/JUYd4P B67uCSlgUporCAQ=
=ZhQ6
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, May 07, 2025 at 08:43:24PM +0200, Simon Josefsson wrote:

I think we should give up on /usr/games and move those
executables to /usr/bin, renaming any binaries that conflict.

This seems somewhat off-topic for a discussion of FTBFS - I hope that
packages don't assume that /usr/games is in the PATH at build time in
any case.

Is it a bug if they do? Buildd's have /usr/games in the default PATH so
I don't think we notice now.

My archive rebuild now uses PATH=/usr/bin so I will get breakage for any >package that FTBFS because of missing /usr/games in PATH. If this
causes too much problems, I'll probably modify it to use >PATH=/usr/bin:/usr/games unless there is some clarification if this is a
bug worth reporting.

It seems really unfortunate to me that /usr/games continues to generate so much discussion :)

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmgbs7wtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh zGYP/0VvEIEN6Zj3/7YjN3ZYS7jKPcR1Dp0TQVUwYnwGLrHcsvljFIEXLue4+qDI MVcYrtsTMNGEEPAF7NZPLGAwlN2sMdqPbPukShEfIpGa9UbMGnwFa3jA8F33G9jA gqblfMoR3OWPvv8hKWAqHcmk6tPzwVIvyglM6UJxFRvoK/aBgMHy/zksssmLZmEU G+OCpJo61y63rdhXd1vw1sRnel6FivgjpeUd1GMunAB0CrWy2VfxQiuIsrqgV7Td cwgTfXSzHWPsCRAKE1ZJky87bLMLJqWrSbeLFYqtQHla5E9dSakR8ds2z0xck+Lf OSIxDW7sems+SCdbuNlRKaWX/q/VsxO2fC2c+WZ+UTsj2FKD/j6ERG7QDDRoD4PL d/JUy2q6CJRC1Y1e/WLtmD1+u8P4LmjO6RM3EwlRTbFt7cjHgIsYPYNOV9KPKCQr 1EX7A7cMgiZTlT+KGmo7GQ1msAl+NMvixE+5UyzSiKemeXeHgRs3ZpBBlRh4UZFn sJQH/UjIYc9STmVFi8IEZShbY28k1AbMDNF93etKrfbWBK/Cvugy0AgkGdtKXLy8 jaWFkq9+a6LZDw0A5TBnw9r/L0Z+tc1pN2C5ofWWQEO9m8EKWoRsA9Q+Ik/Cctz4 NCQ8K517uXJQFMAz51C5FD2u3t2qmXFcHi3CAbWHSPRj6FNw
=FeLJ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 07 May 2025 at 20:43:24 +0200, Simon Josefsson wrote:

Simon McVittie <[email protected]> writes:

I hope that
packages don't assume that /usr/games is in the PATH at build time in
any case.

Is it a bug if they do? Buildd's have /usr/games in the default PATH so
I don't think we notice now.

That's not clear. Different developers have different interpretations of
what "packages must build successfully from source" means - as a minimum
they need to be buildable on our official buildds, but the more
differences from that we're willing to support, the more likely it is
for users and developers to be able to rebuild a package successfully
with changes of their choice. I think the rough consensus is "packages
should build successfully on normal systems", and then we inevitably get
into arguments about whether a particular system is or isn't normal.

As a data point, debuild(1) sanitizes PATH to /usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 by default, if I'm reading correctly.

I'd personally report "FTBFS without /usr/games in PATH" as non-RC if I happened to notice it, with the suggested patch being something like adding

export PATH = ${PATH}:/usr/games

in d/rules (because if there is a possibility that we might want to
reopen #567033 and merge /usr/games into /usr/bin, then hard-coding
the absolute path of a /usr/games/foo in another package is probably
not advisable).

If I'm reading debuild's code correctly, then Severity: normal or even important might be justifiable, because rebuilding a package for a local
change by using debuild seems like a fairly normal use-case.

My archive rebuild now uses PATH=/usr/bin so I will get breakage for any >package that FTBFS because of missing /usr/games in PATH.

If you're willing to report those as usertagged non-RC bugs, I think
that would be helpful.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 7/5/25 a las 21:44, Simon McVittie escribió:

That's not clear. Different developers have different interpretations of what "packages must build successfully from source" means - as a minimum they need to be buildable on our official buildds, but the more differences from that we're willing to

support, the more likely it is for users and developers to be able to rebuild a package successfully with changes of their choice. I think the rough consensus is "packages should build successfully on normal systems", and then we inevitably get into
arguments about whether a particular system is or isn't normal.

No, I don't think that's the consensus. Policy says "must", not "should".

You could probably say that the "must" only applies to "normal systems", but
by using both "should" and "normal" in your characterization of "consensus", you are already deviating two steps from what Policy says. If you think Policy does not really represent the consensus, you should probably propose an amendment.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Santiago Vila <[email protected]> writes:

El 7/5/25 a las 21:44, Simon McVittie escribi�:

That's not clear. Different developers have different

interpretations of what "packages must build successfully from source"
means - as a minimum they need to be buildable on our official
buildds, but the more differences from that we're willing to support,
the more likely it is for users and developers to be able to rebuild a package successfully with changes of their choice. I think the rough consensus is "packages should build successfully on normal systems",
and then we inevitably get into arguments about whether a particular
system is or isn't normal.

No, I don't think that's the consensus. Policy says "must", not "should".

You could probably say that the "must" only applies to "normal systems", but by using both "should" and "normal" in your characterization of "consensus", you are already deviating two steps from what Policy says. If you think Policy
does not really represent the consensus, you should probably propose an amendment.

But does Policy say anything about the PATH variable content when
building packages? I haven't found anything that cover this. The
closest I can find seems to be:

https://www.debian.org/doc/debian-policy/ch-opersys.html#environment-variables

But that is for run-time not build-time.

/Simon

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmgb0awUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFok0lAQDf3kTfmQTn 2lw36wNmCYQXxFQuUnBnI7TJZ4Tg75j3bQEAmwZwbHX0IC+DsyaSBLU8EQ+srduP 2/omXOWd2uCMego=9pMi
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 7/5/25 a las 23:33, Simon Josefsson escribió:

You could probably say that the "must" only applies to "normal systems", but >> by using both "should" and "normal" in your characterization of "consensus", >> you are already deviating two steps from what Policy says. If you think Policy
does not really represent the consensus, you should probably propose an amendment.

But does Policy say anything about the PATH variable content when
building packages?

Certainly not. Usually, using sbuild is considered the standard
to build packages, and many people would not accept a FTBFS bug
being serious if it does not happen when using sbuild. This
would probably disqualify a non-standard PATH as a reason
to report those bugs as serious.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-07 18:18:25 +0200, Simon Josefsson wrote:

Vincent Lefevre <[email protected]> writes:

On 2025-05-07 14:40:01 +0200, Simon Josefsson wrote:

I think a reasonable conservative system policy is PATH=/usr/bin and
anything beyond that is something the user or system administrator have
to add. I think we should give up on /usr/games and move those
executables to /usr/bin, renaming any binaries that conflict.

I disagree. root should not have games in his path. This could also
annoy non-root users.

That is a good point. Hmm. There is a lot more in /usr/bin that I
wouldn't want root to have in PATH either, so I'm not sure I agree that
the /usr/games exception gives root sufficient protection. Given that
it is permissable to have naming conflicts as in /usr/bin/foo and /usr/games/foo, I would prefer the situation where everything under /usr/games was moved to /usr/bin and renamed on naming conflicts. Then
root doesn't have to consider the possibility that invoking 'foo' may
somehow end up running /usr/games/foo instead of /usr/bin/foo depending
on PATH confusion.

Note that this is not just for protection, but also for command
completion. Having many executables makes completion less useful.
Non-root users may currently drop /usr/games from their path.

--
Vincent Lef�vre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Vincent Lefevre <[email protected]> writes:

On 2025-05-07 18:18:25 +0200, Simon Josefsson wrote:

Vincent Lefevre <[email protected]> writes:

On 2025-05-07 14:40:01 +0200, Simon Josefsson wrote:

I think a reasonable conservative system policy is PATH=/usr/bin and
anything beyond that is something the user or system administrator have >> >> to add. I think we should give up on /usr/games and move those
executables to /usr/bin, renaming any binaries that conflict.

I disagree. root should not have games in his path. This could also
annoy non-root users.

That is a good point. Hmm. There is a lot more in /usr/bin that I
wouldn't want root to have in PATH either, so I'm not sure I agree that
the /usr/games exception gives root sufficient protection. Given that
it is permissable to have naming conflicts as in /usr/bin/foo and
/usr/games/foo, I would prefer the situation where everything under
/usr/games was moved to /usr/bin and renamed on naming conflicts. Then
root doesn't have to consider the possibility that invoking 'foo' may
somehow end up running /usr/games/foo instead of /usr/bin/foo depending
on PATH confusion.

Note that this is not just for protection, but also for command
completion. Having many executables makes completion less useful.
Non-root users may currently drop /usr/games from their path.

I challenge that may be pre-mature optimization:

jas@kaka:~$ ls /usr/bin/|wc -l
4675
jas@kaka:~$ ls /usr/games/|wc -l
21
jas@kaka:~$

The majority of games I had installed seems to be from Gnome and I think
they could just as well be in /usr/bin.

/Simon

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmgcBAEUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFojxkAQDtOZ9z6dHg ZOaLzu2ZvorHi6JyAG9OyAOSmJiDLL19ZAEAtWbZ52HdJTakhTKDHLMfwQXWKjOI hcfaAz+EyZgB9QA=/Aa4
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-05-08 03:08:17 +0200, Simon Josefsson wrote:

I challenge that may be pre-mature optimization:

jas@kaka:~$ ls /usr/bin/|wc -l
4675
jas@kaka:~$ ls /usr/games/|wc -l
21
jas@kaka:~$

Indeed. I thought that there were a lot more in /usr/games.

--
Vincent Lef�vre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
On 2025-05-09 at 13:15, Vincent Lefevre wrote:

On 2025-05-08 03:08:17 +0200, Simon Josefsson wrote:

I challenge that may be pre-mature optimization:

jas@kaka:~$ ls /usr/bin/|wc -l
4675
jas@kaka:~$ ls /usr/games/|wc -l
21
jas@kaka:~$

Indeed. I thought that there were a lot more in /usr/games.

It may depend on exactly what has and has not been installed.

$ apt-file search /usr/games/ | wc -l
1353

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAmgeOsUACgkQBKk1jTQo Mmtg4A/8DZgS6N0bmQVjEAleuxZpSeopJaFbR1J24EE8+acvX0MiAtSlAKcj4UJD KqNNrpdl42oIjF2cib5ekilR3KGsGlaOMX+rU8SHaPzUnXE/vOoivthlEdp7d3A8 Uyy8zc+y77isLobCzGYjnd/T+3LHKnvFttkob1+cPi0ynHUhSg6pfrAdY+8qKp3Z 58X287vLSUkRCm+loixZn66xax5z5cs75vTiZdDnePRcRV5DQaUs8UXk63Ve6DP3 iOn8U5FQqgPRgW2CHkkDxc1vi98f2sYkzczvOEoPFGo+1WNLx0tM6se0GVlH+mGS ZFam4fxQ9SIubFt3TVFv7pByNrOP002YUl0zh4Hnsa9vtxJ690JvltAB5OtdsjbN XgcUeX0++qngoqGTzOSnJyNRBkdtQtdtraxmLU8Z4phE8ec1xpEhNGWDZA2BBfOl aXLTu5+tdM9o7WzTM1dbGKxeCFuNpBm/3hJUxHcurENzaLeW6XyIZAZfVX0qnuRK JhFmIL/Y2woP4SdC8vjj7gUvyaqA6tytpn49YOzEcPFnPWjYKvNG65BQytRxee3p dRef6ap3D4Z+cTj0ITwP7u8krGNLyWPsUV/JbyToW2CdovqcC9vboz+UW6Pd8tK/ rrB2AjnkpOJEhvQDs3soE7aQBCLx

XPost: linux.debian.bugs.dist

Hi Simon,

On 06/05/2025 16:24, Simon Josefsson wrote:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104784

Nice catch. That's an interesting failure mode, probably another one
that was not completely anticipated by sponsors of /bin -> /usr/bin
directory aliasing, and it's likely to affect a number of projects using wrapper scripts.

This is indeed a bug in the gradle package. My own build scripts are
always calling /usr/bin/gradle explicitly so they would not be impacted,
but it's definitely worth fixing as there is currently no easy way to do
that with debhelper's gradle buildsystem.

FTR, from the point of view of the upstream project Gradle isn't
supposed to be invoked with a command found through the PATH, and isn't
even supposed to be installed at a known place on any system. The
canonical way to use it is to run ./gradlew from the root of the project
you want to build (that is supposed to have a few bootstrap binaries
checked in along the project) and then let the thing happily download
the whole Internet to get the specific Gradle release(s), JDK(s) and all
the dependencies needed to build, run and test the project.

As official Debian packages can obviously not be built this way for
multiple good reasons, a package-specific default location is hardcoded
into the packaged Gradle so it can use that as a last resort to find its installation root when the relative path guesses fail. We want to keep
the relative path mechanism as it's convenient for testing and using
multiple versions on a system.

There are packages that invoke Gradle during package builds that will
FTBFS until that bug is fixed.

Part of the issue is that the debhelper gradle class currently needs
gradle to be in the PATH and lacks a way to pass a different launcher
path. I'm also planning to fix that later.

Thank you for reporting this.

Cheers,

--
Julien Plissonneau Duquène

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)