Hi! On Sat, Nov 09, 2024 at 09:14:48PM +0100, Daniel Gröber wrote: > 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. Already had this in my calendar $ cat ~/.ratrun/Remove\ bin\:httpfs2\ from\ sid\=forky 2025-06-01 but added note to d/control, which seems best if I pass before then.
> 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. I usually upload to mentors.d.o so this is obviously a little different, and (last time I checked) wasn't really outlined there. > 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. Agree; likewise. > > 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. > [...] > 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 :) I'd say 1-1~ because it's the version we define and have control over, whereas 0.1.4-2~ is based on some archive state somewhere at some point. But for our case it's a wash. > > > > 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. We'd only be hijacking if bin:httpfs2 were still in sid, as you say; it isn't, so AFAICT this is perfectly-well-sanctioned, and a replacement like this is quite common (well, in the decroded-ass salvage packages I usually deal with, anyway). In the umview removal (#1085454 #1085456 &c.), we've replaced src:fuse-umfuse-iso9660's fuseiso9660 with src:fuseiso's fuseiso (and fuseiso9660 transitional Depends: fuseiso) in #1085688, pretty much exactly like src:httpfs2/src:libcurlfs. Actually this /was/ a binary package hijack (0.3-2 -> 20070708-6), because the RMs are yet to clear. Victimless crime. The same thing is planned/staged for src:fuse-umfuse-ext2/src:e2fsprogs. What I could've done instead for this is salvage src:httpfs2 and keep the name, but replace the guts with libcurlfs. Same difference, realistically? (This is what happened with src:fuse-umfuse-fat in #1085458, and half of my DDPO.) If someone wants to reintroduce src:httpfs2 (somehow & god forbid), and have it make bin:httpfs2, it'd need to be version >1 or epoch >0, yeah. But that's their version to bumpo and epoch to justify. Thanks for all your help, наб
signature.asc
Description: PGP signature
