Debian Policy 4.7.1.0 and program names

[Vincent Lefevre]

Hi,

On 2025-02-20 17:51:40 +0800, Sean Whitton wrote:
> I just pushed version 4.7.1.0 of the Debian Policy Manual and related
> documents to the binary-NEW queue for sid.
> Below you will find the significant normative changes from the
> previously-announced release of Policy (4.7.0.0).
[...]
> 10.1
> Two different packages must not install programs with different
> functionality to the same filenames, even names under different
> directories, when the directories are on the default PATH.
[...]

What about existing packages with the same program name?

For instance,

https://packages.debian.org/sid/amd64/lam4-dev/filelist has
/usr/bin/hcc

and

https://packages.debian.org/sid/amd64/uhexen2/filelist has
/usr/games/hcc

and I'm quite sure that the hcc programs have different functionality.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

Advice for directory to symlink transition

[Timo Röhling]

Hello,

I have run into an unexpected quirk of dpkg (I think) and would like 
to solicit some advice on how to handle it.


For better cross building/multi-arch support, I recently moved a 
bunch of files from python3-numpy to python3-numpy-dev. More 
precisely, I moved


/usr/lib/python3/dist-packages/numpy/_core/include
/usr/lib/python3/dist-packages/numpy/_core/lib
/usr/lib/python3/dist-packages/numpy/random/lib
/usr/lib/python3/dist-packages/numpy/f2py/src

to an arch-dependent location and replaced them with symlinks. The 
symlinks are intended to retain directory layout compatibility with 
upstream, so anyone how does not care about cross building is not 
inconvenienced by my create shuffling.


This worked great for the former two directories, but the latter two 
are left as empty real directories, not symlinks, after an upgrade.


I assume it is because the _core directory is new in NumPy 2, so 
dpkg can just create the symlinks at unpack time. The latter two 
directories need to be transitioned from a real directory in NumPy 1 
to a symlink during the package upgrade. Apparently this step fails, 
leaving an empty directory instead.


The question is, how do I fix this? I could add some code to 
postinst to check if there is an empty directory where a symlink 
should be. Is this a reasonable approach?



Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: Advice for directory to symlink transition

[Simon Richter]

Hi,

I assume it is because the _core directory is new in NumPy 2, so dpkg 
can just create the symlinks at unpack time. The latter two directories 
need to be transitioned from a real directory in NumPy 1 to a symlink 
during the package upgrade. Apparently this step fails, leaving an empty 
directory instead.


The way I understood it, dpkg does not track the type of files, only 
ownership. Multiple owners are permitted, if multiple packages contain 
the same path -- conflicts are checked and resolved only at unpack time.


So what happens is that the symlink is unpacked, and the resolution rule 
decides in favour of the directory, but the new package also shares in 
the ownership of this path, so it is never removed.


Guillem is working on a branch of dpkg that tracks types and other 
metadata as well, which would probably detect and report this as a file 
conflict. Not sure if the "directory wins against symlink without 
causing an error" resolution rule would remain here.


I think this can be fixed only with a Conflicts to make sure packages 
that provide the old path as a directory are removed or upgraded before 
the package providing the symlink is unpacked.


I *think* (but I haven't tested it) that if the package unpacking the 
symlink is also the last remaining owner of the directory and the 
directory is empty, then the unpack should succeed and the symlink 
installed.


The question is, how do I fix this? I could add some code to postinst to 
check if there is an empty directory where a symlink should be. Is this 
a reasonable approach?


I think the preinst is a better place -- it is sequenced closer to 
unpacking, and it has a chance of aborting the unpack if the directory 
is not empty (so you still need the Conflicts against the older packages).


   Simon

Re: Advice for directory to symlink transition

[Andrey Rakhmatullin]

On Thu, Feb 20, 2025 at 10:05:36AM +0100, Timo Röhling wrote:
> Hello,
> 
> I have run into an unexpected quirk of dpkg (I think) and would like to
> solicit some advice on how to handle it.
> 
> For better cross building/multi-arch support, I recently moved a bunch of
> files from python3-numpy to python3-numpy-dev. More precisely, I moved
> 
> /usr/lib/python3/dist-packages/numpy/_core/include
> /usr/lib/python3/dist-packages/numpy/_core/lib
> /usr/lib/python3/dist-packages/numpy/random/lib
> /usr/lib/python3/dist-packages/numpy/f2py/src
> 
> to an arch-dependent location and replaced them with symlinks. The symlinks
> are intended to retain directory layout compatibility with upstream, so
> anyone how does not care about cross building is not inconvenienced by my
> create shuffling.
> 
> This worked great for the former two directories, but the latter two are
> left as empty real directories, not symlinks, after an upgrade.
> 
> I assume it is because the _core directory is new in NumPy 2, so dpkg can
> just create the symlinks at unpack time. The latter two directories need to
> be transitioned from a real directory in NumPy 1 to a symlink during the
> package upgrade. Apparently this step fails, leaving an empty directory
> instead.
> 
> The question is, how do I fix this? I could add some code to postinst to
> check if there is an empty directory where a symlink should be. Is this a
> reasonable approach?

dpkg-maintscript-helper dir_to_symlink


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Packages with a history of security issues and whose packaged version is not up to date

[Raphael Hertzog]

Hi,

On Mon, 17 Feb 2025, Santiago Ruano Rincón wrote:
> Other than to take into account recent activity, I think it is important
> to look for possible reasons for not packaging the version reported by
> uscan, before filing a bug report.

I actually see it the other way. When a new upstream release has not been
packaged into Debian one month after its release, as a user, I'd like to
know why. Having a bug report open would allow the maintainer to comment
and leave some explanation, whatever it is.

It could be that he has no time and would gladly accept help. It could be
that this is not an LTS release and he will only package LTS releases. Or
it could be that it's just a minor release and he intends to update the
package just once a couple of months before the release. Or the new
upstream release requires a new dependency that we don't have yet, and
he's waiting on that, etc.

So provided that we don't spam maintainers with "new upstream release"
bug reports hours after the upstream release, and that we don't open new
bug reports for as long as the former one has not been closed (but instead
update the existing bug with the new information), then I would be 
pretty much in favor of automating the creation of such bug reports.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Packages with a history of security issues and whose packaged version is not up to date

[Andrius Merkys]

On 2025-02-20 15:37, Raphael Hertzog wrote:

So provided that we don't spam maintainers with "new upstream release"
bug reports hours after the upstream release, and that we don't open new
bug reports for as long as the former one has not been closed (but instead
update the existing bug with the new information), then I would be
pretty much in favor of automating the creation of such bug reports.


+1. More documentation on why a package has not been updated would be 
nice to have. Personally, I file bugs on my packages myself to document 
reasons/progress.


Andrius

Bug#1098424: ITP: python-packageurl -- Package URL (purl) spec Python implementation

[Santiago Ruano Rincón]

Package: wnpp
Severity: wishlist
Owner: Santiago Ruano Rincón 
X-Debbugs-Cc: debian-devel@lists.debian.org, 1089...@bugs.debian.org

* Package name: python-packageurl
  Version : 0.16.0
  Upstream Contact: https://gitter.im/package-url/Lobby
* URL : https://github.com/package-url/purl-spec
* License : MIT/X
  Programming Lang: Python
  Description : Package URL (purl) spec Python implementation

Python library to parse and build "purl" aka. Package URLs. See
https://github.com/package-url/purl-spec for details.

This is a build-dependency for cyclonedx-python-lib (ITP #1089871). I
plan to maintain it under the Python Team umbrella.


signature.asc
Description: PGP signature

Bug#1098438: ITP: python-simple-pid -- Simple and easy-to-use PID controller

[Alexander Sulfrian]

Package: wnpp
Severity: wishlist
Owner: Alexander Sulfrian 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-simple-pid
  Version : 2.0.1
  Upstream Contact: Martin Lundberg 
* URL : https://github.com/m-lundberg/simple-pid
* License : MIT
  Programming Lang: Python
  Description : Simple and easy to use PID controller

simple-pid is a simple and easy-to-use PID (proportional-integral-derivative)
controller in Python. It has no external dependencies and is designed to be
robust. It can be used to implement a feedback-based control loop in Python.

I plan to package it inside the Debian Python Team, but I will need a
sponsor for the upload.

Re: Bug#1096150: ITP: forwords -- A very simple but effective tool to learn foreign language words

[Salvo Tomaselli]

Does it include the data files or just software?

If not, does this data exist and is easy to find?


Best

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

https://ltworf.codeberg.page/

signature.asc
Description: This is a digitally signed message part.

Join us in Montreal on March 28th and 29th for a Bug Squashing Party!

[Louis-Philippe Véronneau]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello!

We're happy to announce we will be hosting a Bug Squashing Party in Montreal on
Friday March 28th and Saturday 29th.

The event will take place at the "Ateliers de la transition socio-écologique",
near the Beaubien subway station.

A short registration on the wiki page [1] is required to ease the organization
of the event. On the same page you will find information regarding transport
and other useful things.

Even if you are not a Debian Developer or Contributor yet, but interested in
fixing bugs and helping Debian, don't hesitate to come!

You can find more information about BSPs linked from this BSP's wiki page.

Don't hesitate to contact me if you have questions!

[1]: https://wiki.debian.org/BSP/2025/03/ca/Montreal

- -- 
  ⢀⣴⠾⠻⢶⣦⠀

  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄
-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQTKp0AHB6gWsCAvw830JXpQshz6hQUCZ7dpDwAKCRD0JXpQshz6
hcVGAQD+ubAynxnNhqyMlgU79Wre5U/mP/OgPwSq653Z4VInEwD5ASxkhyGllC5A
KIVlbsE+Gzn/xnLl7TksuMbIoFdVtgc=
=Qzsg
-END PGP SIGNATURE-

Re: Debian Policy 4.7.1.0 and program names

[Michael Biebl]

Am 20.02.25 um 11:13 schrieb Vincent Lefevre:

Hi,

On 2025-02-20 17:51:40 +0800, Sean Whitton wrote:

I just pushed version 4.7.1.0 of the Debian Policy Manual and related
documents to the binary-NEW queue for sid.
Below you will find the significant normative changes from the
previously-announced release of Policy (4.7.0.0).

[...]

10.1
 Two different packages must not install programs with different
 functionality to the same filenames, even names under different
 directories, when the directories are on the default PATH.

[...]

What about existing packages with the same program name?

For instance,

https://packages.debian.org/sid/amd64/lam4-dev/filelist has
/usr/bin/hcc

and

https://packages.debian.org/sid/amd64/uhexen2/filelist has
/usr/games/hcc

and I'm quite sure that the hcc programs have different functionality.



A quick-and-dirty compiled list of conflicting program names:

bin <> games


cappuccino: /usr/bin/cappuccino
cappuccino: /usr/games/cappuccino

golang-chroma: /usr/bin/chroma
chroma: /usr/games/chroma

snap: /usr/bin/fathom
fathom: /usr/games/fathom

lam4-dev: /usr/bin/hcc
uhexen2: /usr/games/hcc

kdesdk-scripts: /usr/bin/makeobj
simutrans-makeobj: /usr/games/makeobj

metar: /usr/bin/metar
flightgear: /usr/games/metar

mono-devel: /usr/bin/monop
bsdgames: /usr/games/monop

morse: /usr/bin/morse
bsdgames: /usr/games/morse

gnome-mousetrap: /usr/bin/mousetrap
mousetrap: /usr/games/mousetrap

node-istanbul: /usr/bin/nyc
filters: /usr/games/nyc

pacman-package-manager: /usr/bin/pacman
pacman: /usr/games/pacman

pinball-dev: /usr/bin/pinball-config
pinball-dev: /usr/games/pinball-config

libmath-prime-util-perl: /usr/bin/primes
bsdgames: /usr/games/primes

sgb: /usr/bin/queen
flight-of-the-amazon-queen: /usr/games/queen

hxtools: /usr/bin/rot13
bsdgames: /usr/games/rot13

rs: /usr/bin/rs
reminiscence: /usr/games/rs

staden-io-lib-utils: /usr/bin/scramble
filters: /usr/games/scramble

singularity-container: /usr/bin/singularity
singularity: /usr/games/singularity

ruby-spring: /usr/bin/spring
spring: /usr/games/spring

raster3d: /usr/bin/worms
bsdgames: /usr/games/worms

libxrt-utils: /usr/bin/xball
xball: /usr/games/xball

sbin <> games
=
sauce: /usr/sbin/sauce
fortunes-de: /usr/games/sauce




OpenPGP_signature.asc
Description: OpenPGP digital signature