[pkg-go] Bug#801593: Bug#801593: Bug#801593: ratt does not find all reverse build dependencies

Michael Stapelberg stapelberg at debian.org
Sun Oct 18 21:10:06 UTC 2015


Okay.

I can’t figure out how to specify multiple binary packages when calling
dose-ceve. The manpage for -r says:

       -r pkgspec
           Using the same syntax as in -c, this option use the reverse
dependency relation to make the transitive closure.
           This option can also be specified as --rcone=pkgspec.

So the manpage for -c says:

       -c pkgspec
           The match of an atomic dependency (a package name p possibly
together with a version constraint c) is the set of all packages in the
repository with name p, and a version that satisfies the constraint c.  The
dependency cone of a package p is the set of all matches of all atomic
dependencies of p, together with their respective dependency cones.  The
package specification pkgspec is a list of packages (separated by a
semicolon), where each package is specified as follows: (name,version).

I started out with the following command invocation:

dose-ceve --deb-native-arch=amd64 -T debsrc -r "golang-golang-x-tools" -G
pkg
deb:///var/lib/apt/lists/ftp.ch.debian.org_debian_dists_unstable_main_binary-amd64_Packages
debsrc:///var/lib/apt/lists/ftp.ch.debian.org_debian_dists_unstable_main_source_Sources

That command returns aptly and etcd, as discussed previously. Now I tried
specifying multiple binary packages, but couldn’t get any combination to
work:

https://paste.debian.net/316796/ (so as to not make this email too long)

So, I’m at a loss. What am I misunderstanding here? Can you please provide
an example invocation of how you think ratt should call dose-ceve in this
specific case?

Also, may I suggest the following improvements to dose-ceve:

1. When -r is specified multiple times, it should not overwrite the package
spec, but amend it. If you think -r should only be specified exactly once,
I suggest dose-ceve should error out when users specify multiple -r values.

2. The manpage ceve(1) should come with an example for pkgspec.

3. Instead of merely stating that the provided pkgspec is invalid,
dose-ceve should tell the user why the pkgspec is invalid, and ideally
include a valid example.

(4. Possibly, the manpage ceve(1) should be worded a bit more clearly with
regards to pkgspec, but perhaps it’s just me…)

Thanks.

On Thu, Oct 15, 2015 at 7:37 AM, Johannes Schauer <josch at debian.org> wrote:

> Hi,
>
> Quoting Michael Stapelberg (2015-10-14 22:25:25)
> > Ah, so dose-ceve operates on binary packages in the invocation that we’re
> > using.
>
> yes. When I talk about source packages I prefix them with "src:" or
> explicitly
> say "source packages". When I talk about binary packages then I will not
> use
> that prefix and will also call them "binary package" except if it's clear
> from
> the context (for example there are only virtual binary packages but no
> virtual
> source packages).
>
> > Is there a way to make it work on source packages instead?
>
> In general: yes. If you want dose-ceve to operate on a source package you
> have
> to let it look for src:golang-golang-x-tools (that selects the source
> package)
> and not golang-golang-x-tools (that selects the binary package).
>
> But this will not find any reverse dependencies because by default nothing
> depends on the source package. This is because by default there is no
> connection between the binary packages a source package builds to their
> source
> package in the package graph. To fix this you'd add the --deb-builds-from
> option which would connect all binary packages to the source package they
> build
> from. The problem here is that this connection would be made for *all*
> source
> packages and not only for src:golang-golang-x-tools. So you would still
> not get
> the desired result (except if you are are also interested in checking
> whether
> rebuilding a source package build depending on your new binary package also
> still lets all source packages build depending on that *new* source
> packages
> binary packages build properly).
>
> > I feel like that would be a tad more efficient, as ratt would not need to
> > extract all binary packages
>
> Extracting all binary packages introduced by your upload is trivial. Just
> look
> at the Binary: field in your .changes file.
>
> > and dose-ceve would not need to parse all the binary index files.
>
> It needs to parse the binary index files anyways because otherwise it
> cannot
> give you transitive reverse dependencies.
>
> So while I have commit rights to dose upstream git I do not see a benefit
> yet
> in adding such a feature.
>
> Thanks!
>
> cheers, josch
>
> _______________________________________________
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20151018/2038eb5b/attachment.html>


More information about the Pkg-go-maintainers mailing list