I would like dgit clone to be able to give you `the source for the
package I am running'.  (It gives you sid by default.)  This involves
knowing the relevant suite, at the very least.

AFAICT this can be done as follows:

Run `apt-cache madison SOURCEPACKAGE'.  Parse the output, discarding
non-matching entries (since binary package entries may appear too).
Perhaps check that the version number matches the installed version.

Extract the URL.  Look in the apt cache(!) to find the InRelease or
Release file.  Extract the `Suite' field.  Extract the `Origin' field
too, and look it up in the dgit config to map it to a dgit distro.

A problem with this is how to know whether the InRelease file is
accurate.  It probably doesn't matter very much if it's not up to date
(since it was at least up to date enough to get the package installed,
if apt installed it).  But what if it is broken somehow, or the
signature didn't verify ?

Also, going behind apt's back like this to look at the cache is pretty
ugly.  But if dgit downloads the file itself, this would still require
dgit to verify the signature somehow.

Ian.

Users who don't know how to quickly find the suite a package came from
probably don't have a good grasp of Debian's distinction between source
and binary packages, either.  So it might be good if dgit resolved
binary package names to source package names as a fallback.

Sean Whitton writes ("Bug#848193: Want "dgit clone <package> RUNNING" or some such"):

Improving that is #844206.

Thanks,
Ian.

Hi,

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
https://people.debian.org/~stapelberg//2017/10/21/pk4.html, which covers
a large fraction of the described use-case, IIUC.

Possibly pk4’s -resolve_only option is of interest, with which we could
re-use the pk4 resolving logic but then run dgit instead.

Hope that helps,

Hello,

Cool!

Yes.  We'd probably want dgit to do the unpack and git init, so it can
pass the right options to dpkg-source.

Sean Whitton writes ("Bug#848193: Want "dgit clone <package> RUNNING" or some such"):

Excellent.  Yes, these tools should be combined.

Thinking about it briefly, I think the obvious possible UIs are:

1a. dgit clone pk4:<search term>

1b. dgit does that automatically if pk4 is installed

2. pk4 --dgit <search term>

Opinions ?

Whatever is done, the result should be documented in dgit-user(7).

Regards,
Ian.

On Sun, Oct 22, 2017 at 4:31 PM, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:

Thanks for the suggestions. Thoughts inline:

This seems fine to me, and I suggest we go with this option.

This seems a bit too magic to my taste. If people prefer 1b over 1a,
perhaps a fallback could be used instead, with a clear error message
such as “<search term> not found. Try installing the pk4 Debian
package to have dgit fall back to resolving via pk4.”?

This is the least desirable option to me, because it would mean that
pk4 needs to integrate with every packaging tool (gbp has also
declared interest), and I think it would be more elegant if we could
do it the other way around.

Michael Stapelberg writes ("Bug#848193: Want "dgit clone <package> RUNNING" or some such"):

Not sure about ":" because that's also used for arch specifications.
(And although you're not _supposed_ to have multiple different
versions of the same multiarch package installed, you might have
forced it.)

I think if we do this then dgit ought to do the pk4 search
automatically if pk4 is installed.  And then you'll get a message like
"did you mean   dgit clone pk4:...".

I have already had bug reports from confused users who tried to `dgit
clone' a binary package name.

So overall my conclusion is that people are going to have different
opinions.  It dgit should support `dgit clone <pk4 search term>'
but this magic should be configurable.

Fair enough.


So, I haven't looked at pk4 at all.  I will do that.  But basically
what I will need is to resolve the search term not only to a .dsc, but
also to a distro and suite name.  There's also the ,-security magic to
be added somehow.  I'm not sure if pk4 has all the necessary knowledge
yet - or indeed whether it wants to grow it.

Ian.

On Mon, Oct 23, 2017 at 11:59 AM, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:

Fair point. Any other separator will do fine. How about a slash (“/”)?


Currently, pk4 resolves to a (srcpkg, srcversion) tuple. We could add
more information, but everything we add will of course make the index
files larger (I’ll need to see by how much). Can you outline what is
necessary for the ,-security magic?

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