Hi наб, Thanks for the update, I have some more review notes:
Development documentation nit: I would add a note to d/control on when Package: httpfs2 can be removed (trixie+1 I suppose) and that a Provides: httpfs2 should(?) be added to libcurlfs when that happens. Sponsorship process with gbp: when gbp is involved the convention is for sponsorees to leave UNRELEASED in d/changelog though that's more important with teams to make sure it's clear to all DDs whether an upload happend yet or not. In any case Sponsors should push the final debian/$version tag (and sometimes minor packaging tweaks to expedite things) so it's usually least error prone to have repo access. Easiest way to do that is to move the packaging repo into the debian/ salsa namespace where any DD has the appropriate access. Please add me as Owner to the repo (@dxld on Salsa) so I can do the move if you agree. Collaborative packaging in git: you pushed your updated version as an unrelated history. That's very out of the ordinary. Simply adding another upstream release in the usual way would have been preferred. I've forcefully merged your new history into my repo with $ git merge origin/debian --allow-unrelated-histories --no-ff -Xtheirs Please don't do that in the future unless absolutely necessary even during initial review it makes it harder for your sponsor to review your changes between rounds -- which is like the whole point of using a VSC for packaging and the sponsorship process in the first place :-) On Tue, Oct 15, 2024 at 08:12:44PM +0200, наб wrote: > > 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. > > Hm. As I read it, the ~ is only really meaningful with a Debian version Right, this shouldn't be in your upstream version. I don't think it's likeley it will matter either way in our case, just trying to keep to best practices where possible. > This indicates to me that this should be "httpfs2 (<< 1-1~)", > since this package supersedes all httpfs2es older than 1, > even if someone has a newer "real" httpfs2 installed locally. Yeah thats what I was thinking. I did some more upgrade experiments to understand whats going on here and why the advice is the way it is from first principles: First off unversioned Breaks+Replaces doesn't work because installing our httpfs2 1-1 transitional package would be blocked completely: libcurlfs : Breaks: httpfs2 but 1-1 is to be installed Alright so we want to include 0.1.4-1.1 and exclude 1-1 at the very least, so the tightest bound to achive that is (<= 0.1.4-1.1). So why is the advice to use << instead of <=? I believe this is to cover the +local1 and similar cases Peter mentions where higher version numbers may be yet to come. For example if we declare (<= 0.1.4-1.1) but the user has a 0.1.4-1.1+local1 installed that that would prevent the upgrade to our transition package. Alright so we don't want to be that tight let's increment the Debian revision and consider (<< 0.1.4-2), what's wrong with that? In our case nothing that I can see, but in the framework of Peter's advice a -2 upload is a real possibility and if someone were to backport it you'd end up with 0.1.4-2~bpo12 satisfying Replaces: (<< 0.1.4-2). I'm not sure that's really a problem but it's not really desired and thinking about the consequences seems harder than just excluding the backport version from the relation by appending ~. So I'm still torn on which of 0.1.4-2~ and 1-1~ is technically better, but I'm pretty sure either will be fine in this case :) > > > 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. > > Sure, I can justify this as "this is httpfs2 1, too". I am a bit worried we may be subverting policy here since a new httpfs2 upstream release and subsequent re-introduction would now have to employ an epoch to override our transition package, but given that httpfs2 has been removed I reckon it's version namespace is up for grabs. > > 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. > > On principle, I never mix downstream packaging with the upstream, > and maybe I'm too gbppilled, but the standard gbp setup I find much easier. > Plus, this makes it impervious to #986320! > (if it's ruled as "don't native unless it's Debian infra"; > unlikely, given we have 822 native packages, but). Eh, I don't see that bug reaching consensus ;) Your call. On Tue, Nov 05, 2024 at 11:00:11PM +0100, наб wrote: > On Tue, Oct 15, 2024 at 08:12:45PM +0200, наб wrote: > > Made libcurlfs 1, updated the gits to have 1-1 (and << 1-1~). > > Doesn't build on CI due to the perl transition > > It does now! and ci.debian.net apparently actually runs tests with > Restrictions: isolation-machine so they will probably get exercised :) Nice. --Daniel
signature.asc
Description: PGP signature
