Michael Stapelberg writes ("Bug#848193: Want "dgit clone <package> RUNNING" or
some such"):
> On Sun, Oct 22, 2017 at 4:31 PM, Ian Jackson
> <[email protected]> wrote:
> > 1a. dgit clone pk4:<search term>
>
> This seems fine to me, and I suggest we go with this option.
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.)
> > 1b. dgit does that automatically if pk4 is installed
>
> 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.”?
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.
> > 2. pk4 --dgit <search term>
>
> 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.
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.
