Hi наб, On Mon, Sep 09, 2024 at 03:44:31AM +0200, наб wrote: > > 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...
Hmm, yeah. Now that I think about it again the httpfs2 transitional package would depend on libcurlfs and it having a Conflicts: httpfs2 would probably make httpfs2 uninstallble :) The only nit I have is we may want to add a ~ at the end of the replaces+breaks constraints. See https://lists.debian.org/debian-devel/2024/10/msg00094.html for a similar discussionbut it's probably not critical in this case. > > 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. I'm afraid so. > > 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). Since you control the upstream version number I would prefer it if you simply bumped it to be larger than httpfs2's instead of using an epoch here. If you do want to go with the epoch per d-policy (5.6.12 `epoch`) you should consult d-devel before doing so. While this is a new package we are squatting on the httpfs2 name with the transitional package so I think it would still be required. Come to think of it: why aren't you packaging this as a native package if you're upstream anyway? Means you only need one git repo and only one branch. No need for gbp's upstream/debian branch distinction either. Just makes things simpler. > This configuration fresh-installs and upgrades fine for me on bookworm. > I've updated the gits thus. Looks fine to me too. Autoremove even picks up httpfs2 for removal. Neat. I didn't know that handles transitional packages! $ apt-get autoremove Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be REMOVED: fuse httpfs2 libfuse2 > 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?). That's a question for the salsa CI team I haven't ventured that deep yet: https://salsa.debian.org/salsa-ci-team/pipeline#support-for-salsa-ci-use Feel free to CC me if you end up sending an email. --Daniel
signature.asc
Description: PGP signature
