Hi! On Sun, Sep 08, 2024 at 03:34:14PM +0200, Daniel Gröber wrote: > On Sat, Sep 07, 2024 at 03:31:16AM +0200, наб wrote: > > * Package name : libcurlfs > > Version : 0 > > Upstream Contact: наб <nabijaczlew...@nabijaczleweli.xyz> > > * URL : https://sr.ht/~nabijaczleweli/libcurlfs > > * License : 0BSD > > Programming Lang: C++ > > Description : mounts remote HTTP/HTTPS URLs as a FUSE filesystem > this package looks useful. I'll sponsor it. Thanks for working on this. thanks :)
> > This was written as a direct replacement for httpfs2 > Looking at d/control, you don't seem to declare the replacement properly. Oh, it's definitely wrong; ideally I wanted to have the upgrade happen httpfs2 -> libcurlfs without a transitional package (hence also the Provides:); having now tested this, I don't think that's possible. > You need Conflicts+Replaces, not +Breaks, > cf. > https://www.debian.org/doc/debian-policy/ch-relationships.html#replacing-whole-packages-forcing-their-removal > > Quoting policy: > > When one binary package declares a conflict with another using a > > Conflicts field, dpkg will refuse to allow them to be unpacked on the > > system at the same time. This is a stronger restriction than Breaks, > > which prevents the broken package from being configured while the > > breaking package is in the “Unpacked” state but allows both packages to > > be unpacked at the same time. > > Since you include an overlapping httpfs2 symlink in your package Breaks is > inappropriate as even just unpacking would cause a file conflict with > httpfs2. This gave me lintian conflicts-with-version, which points out that > In particular, when moving files between packages, > use Breaks plus Replaces, not Conflicts plus Replaces. and https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces agrees on this point; I think this best describes what we're trying to do here, since... > Further > Provides: httpfs2 (= 1) > > doesn't look right. I don't think you need a versioned provides here since > no other packages depend on httpfs2, but I don't have much experience with > replaceing packages. > > I think it would also be useful to just take over httpfs2 on upgrade from > bookworm, but I can't find any relevant advice on how one might do that. I > thought perhaps the provides with a higher version number than httpfs2 in > stable would encourage apt to upgrade from httpfs2 to libcurlfs on it's own > but I didn't see that happen when upgrade testing in my local repo setup. My testing agrees, so I think the canonical way of doing this is having a transitional package, as you say. > One idea I had was to just to build a httpfs2 pseudopackage that depends on > libcurlfs as part of src:libcurlfs. ...so httpfs2 Arch=all transitional package Depends: libcurlfs libcurlfs Breaks+Replaces: httpfs2 (<< 0.1.5) since we're moving /bin/httpfs2 &c. from httpfs2=0.1.4 to libcurlfs=0-1. This also means we need to start this package at epoch 1 (since 0-1 < 0.1.4-1.1+b1, and we want a httpfs2 that sorts newer). This configuration fresh-installs and upgrades fine for me on bookworm. I've updated the gits thus. On the topic of the gits ‒ do I really need Restrictions: isolation-machine on the autopkgtest? it works fine as a regular user in a chroot or container, /if/ fuse.ko is loaded (indeed, I patch it out on builds.sr.ht CI https://git.sr.ht/~nabijaczleweli/libcurlfs.deb/commit/de6a8f0d58534cd66c81ec63302f6d5e78a8b0b2) but the Salsa autopkgtest CI step naturally doesn't have fuse.ko loaded, and it can't auto-load from the chroot/container/whatever, but it also can't provide isolation-machine so it skips it. So I don't really know if it works (or if I need an explicit load step?). Best,
signature.asc
Description: PGP signature
