Hi, On Sun, Nov 10, 2024 at 12:59:11AM +0100, наб wrote: > 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.
That's just a special case of running out of time for Debian work. Best to always be prepared for this common case ;-) > > 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. Yeah the docs and perhaps even workflow consensus are lacking, no worries. Its not really important here I just decided to mention it since it's relevant if you ever do any team git work. > > 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. Seems like a reasonable tie breaker :) > > 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.) Right if we'd reintroduced src:httpfs2 we could have also bumped the version is whatever way we like so indeed there's no difference. > 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. Yeah and that's what got me thinking about what the intention of policy is here. AFAIK the "ask d-devel about epochs" policy is just so people don't use them gratuitously when there's other options (mainly +really I guess) but considering whether there may be other reasons I'm not aware of got me thinking. --Daniel
signature.asc
Description: PGP signature
