As a programming-skilled user of Debian (and also Ubuntu), I often want
to inspect the source code of a package running on my system, to help me
work out why it's behaving as it is. Less commonly, I also want to make
a minimal modification to the source (e.g. applying one bug-fix patch
from a later upstream version), and carry that patch through subsequent
security updates.

For both of these purposes, I want to start from a version of the
package's source code which matches the package as it is actually
installed on my machine (or, if I haven't installed it _yet_, the
version that would be installed by the obvious 'apt install' command).
If I'm investigating the behaviour of my actual machine, I don't want to
be misled by differences between the package as installed and some very
different version (e.g. dgit's default of checking out from sid). And if
I'm replacing the package on this machine, any changes _other_ than the
intended one risk incompatibility with the rest of the system.

'apt source' does this by default, because its source package repository
configuration is updated in parallel with the binary package
repositories. As far as I can see, there isn't _quite_ a corresponding
option in 'dgit clone'.

I see in the man page that I can specify the suite by name, via a
command like 'dgit clone coreutils bullseye'. But this requires me to
know the name of the suite running on my current system, or to look it
up. (Not _hard_, but it's an extra manual step.) It would be helpful if
there was a magic keyword I could put in place of the suite name, such
as "LOCAL" or "HERE" or something like that, which means "whatever suite
the host machine is running".

I suggest making it a magic keyword _in_ the suite name slot, rather
than a separate option like --local, because then I could set it as the
default behaviour via 'git config dgit.default.default-suite HERE' (or
whatever). Then the shortest 'dgit clone' command would do the thing I
most often want, and I could put that in my standard account-setup
scripts, without having to remember to reset it after an OS upgrade.

(Or maybe HERE would expand to the _main_ suite name, so that I'd have
to say something like "HERE,-security"? That would be cumbersome to
write on the command line every time, but if I were putting it in git
config then I wouldn't care – I'd only have to do it once.)

Cheers,
Simon

Simon Tatham writes ("Bug#1123834: dgit clone: placeholder suite name for local machine?"):
...
...
...

Thanks.  This kind of use case has been discussed before, in eg
#848193 and #877969.  The hard part is deciding on the details of what
the UI and behaviour shouold be.

And, you have some interesting UI suggestions.  So, thanks!

Ian.

Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:

Yes. I see in the other tickets that there's at least a distinction
between

 (a) the most up-to-date version from the combination of package suites
     that my apt is currently configured to talk to

 (b) the specific version that is installed right this instant on my
     machine, even if a later version is available via an 'apt update' I
     haven't got round to running.

(I believe 'apt source' does (a).)

For my purposes I don't especially care about the difference, because I
apt update frequently in general, and moreover, if anything on my system
is actively confusing me, I'll probably do a precautionary update before
I put any real effort into figuring it out, in case it's been recently
fixed. So if (a) and (b) don't agree with each other, then my own
opinion is that that's on me, and I don't mind which dgit does.

But I can certainly see that other people might care!

Cheers,
Simon