Re: RFC: dpatch - past, present and future
Guillem Jover <guillem@debian.org> writes:
>> But if your goal is really to get rid of it, you could just as well file
>> wishlist bugs on all packages build-depending on it, usertag them and
>> increase their severity slowly. Wishlist for now, normal in the next
>> release cycle and important/RC in the cycle where you want to drop it?
>
>> FWIW, we managed to get rid of 2/3 of dbs build-dependencies by filing such bugs:
>> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=hertzog@debian.org;tag=drop-dbs
>
> Given there's at least around 800 source packages (as Gergely pointed
> out, and checking for embedded dpatch in source might reveal some more
> maybe). I think filing bug reports for these right now would be too
> much, and I'd propose to add a lintian check first, and wait until the
> numbers decrease substantially before filing them.
Since I plan to phase out dpatch by 2017, there's plenty of time to file
those ~800 wishlist bugs. I'm not worried. This gives me plenty of time
to get it done without spamming the BTS. About 3 bugs a week on average
sounds low profile enough, and it's comfortably low enough to allow me
to actually do the patches properly.
I'm not entirely sold on the lintian check idea, either, but that might
be my lack of tea today. (Update, after a cup of tea: I'll send a patch
against lintian once 2.0.32 is uploaded to unstable.)
As for embedded dpatch: that's usually something very different to what
is currently packaged as dpatch. I do not wish to care about that, and
as such, is not and will not be included in my removal plans. (However,
if someone takes up the task, so much the better! It just won't be me.)
--
|8]
Reply to: