1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Advice for directory to symlink transition

    From Timo =?utf-8?Q?R=C3=B6hling?=@21:1/5 to All on Thu Feb 20 10:10:01 2025
    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 │
    ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

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

    iQIzBAEBCgAdFiEEmwPruYMA35fCsSO/zIxr3RQD9MoFAme28F0ACgkQzIxr3RQD 9MrWAA//VkcI22gVeNEnAaIc5O/rvXPLElSuKGuO3jljs+RrlKchRsZH8Qf0Axm8 pt0PfG5tdqM4uhjdoa9cyatHLXiTe5kqtVEigD5YTKQjdWLOC/wMyWRL2pNFBIKe Zc//t9PSJlSdIkULYbGxkEmTABc3ukUnHvADLou2089Pv9yYJiKtjLahJN+4lDJc uaTPr8liA3Bt/98TSoIezBAuDk5ULVJwbpSmjyhdi69gfBiplIV2wmD2JLN1hZL2 Fq3prGWWAEOc548fdpbJprzbef7kDkNPvfdeJ59/6bjLrB7MUZFv72HfevT9/p67 8EVB/kDLiU7kk7DIEAaVPE+W5kdtSKRqt1n5eq/RuTj
  • From Andrey Rakhmatullin@21:1/5 to All on Thu Feb 20 10:30:01 2025
    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

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

    iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAme29Y4tFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh E9cP/1iDaYDG1ZizMNc8ivZOkXg5liDS7MxePGVg1AdNhIh63wlx8xx8nTjRyCbG 755RffvcxGK5USlrmlw3pxLnW99yHJlWK0kkB6+38a7ZeSnB/6gSiC+aKrhBRd3K NVtixLI6rX1qWVGqUGFXyD/5WmOZdJALvEXXQBTiPeWBNkTeP7Ky1FMbTP3ktJ2X d79MC9NroB0n50YMXHQ+5e1HBuDyCtZWFMIDX1FY97KOU4ubOY3skyX9NESkiC6d fuNx7yZsdVldlRlMMDGXLerInEXMkYd3TyKjQO6a4HXke5Og+zk6E9F4QlldZ2Pa aFdD9ma7elczWdMn/QrUxaou3co69STcL/qzywd1su/9uymM3XlcElGJnPLimeYm iTxCMddro/+JE3nGgf/Ci043//W7DRJd4MVQ5/rzcPINbywkPKEmnQXU8df4HDnB oIHuwq9ntt9ylGW5z7BZRY0onUfkj0J8gPnwbkxAzCxTsiIim/bccI3HXD6Z4lVv iy69qzxLsO3WZyzOm7MiVED9VKxKi04GVt3ZvHwO6jEkHwKIjLnE5UGqrYzgnFKG pMEH1kOPsNqpeM/hAT/qRLhwqWSptGRKkg7riLQAEF0eWdWHBaFP8WcRJsZ/SN94 LTiMvcaE5ZAfuJF8hLP+uwhuHgx4ml9nBivEYOhAtD4IawWS
    =okk5
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Richter@21:1/5 to All on Thu Feb 20 10:30:01 2025
    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

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