<div dir="ltr">Okay.<div><br></div><div><div>I can’t figure out how to specify multiple binary packages when calling dose-ceve. The manpage for -r says:</div></div><div><br></div><div><div>    -r pkgspec</div><div>      Using the same syntax as in -c, this option use the reverse dependency relation to make the transitive closure.</div><div>      This option can also be specified as --rcone=pkgspec.</div></div><div><br></div><div>So the manpage for -c says:</div><div><br></div><div><div>    -c pkgspec</div><div>      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).</div><div><br></div></div><div>I started out with the following command invocation:</div><div><br></div><div>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<br></div><div><br></div><div>That command returns aptly and etcd, as discussed previously. Now I tried specifying multiple binary packages, but couldn’t get any combination to work:</div><div><br></div><div><a href="https://paste.debian.net/316796/">https://paste.debian.net/316796/</a> (so as to not make this email too long)<br></div><div><br></div><div>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?</div><div><br></div><div>Also, may I suggest the following improvements to dose-ceve:</div><div><br></div><div>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.</div><div><br></div><div>2. The manpage ceve(1) should come with an example for pkgspec.</div><div><br></div><div>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.</div><div><br></div><div>(4. Possibly, the manpage ceve(1) should be worded a bit more clearly with regards to pkgspec, but perhaps it’s just me…)</div><div><br></div><div>Thanks.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 15, 2015 at 7:37 AM, Johannes Schauer <span dir="ltr"><<a href="mailto:josch@debian.org" target="_blank">josch@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Quoting Michael Stapelberg (2015-10-14 22:25:25)<br>
<span class="">> Ah, so dose-ceve operates on binary packages in the invocation that we’re<br>
> using.<br>
<br>
</span>yes. When I talk about source packages I prefix them with "src:" or explicitly<br>
say "source packages". When I talk about binary packages then I will not use<br>
that prefix and will also call them "binary package" except if it's clear from<br>
the context (for example there are only virtual binary packages but no virtual<br>
source packages).<br>
<span class=""><br>
> Is there a way to make it work on source packages instead?<br>
<br>
</span>In general: yes. If you want dose-ceve to operate on a source package you have<br>
to let it look for src:golang-golang-x-tools (that selects the source package)<br>
and not golang-golang-x-tools (that selects the binary package).<br>
<br>
But this will not find any reverse dependencies because by default nothing<br>
depends on the source package. This is because by default there is no<br>
connection between the binary packages a source package builds to their source<br>
package in the package graph. To fix this you'd add the --deb-builds-from<br>
option which would connect all binary packages to the source package they build<br>
from. The problem here is that this connection would be made for *all* source<br>
packages and not only for src:golang-golang-x-tools. So you would still not get<br>
the desired result (except if you are are also interested in checking whether<br>
rebuilding a source package build depending on your new binary package also<br>
still lets all source packages build depending on that *new* source packages<br>
binary packages build properly).<br>
<span class=""><br>
> I feel like that would be a tad more efficient, as ratt would not need to<br>
> extract all binary packages<br>
<br>
</span>Extracting all binary packages introduced by your upload is trivial. Just look<br>
at the Binary: field in your .changes file.<br>
<span class=""><br>
> and dose-ceve would not need to parse all the binary index files.<br>
<br>
</span>It needs to parse the binary index files anyways because otherwise it cannot<br>
give you transitive reverse dependencies.<br>
<br>
So while I have commit rights to dose upstream git I do not see a benefit yet<br>
in adding such a feature.<br>
<br>
Thanks!<br>
<br>
cheers, josch<br>
<br>_______________________________________________<br>
Pkg-go-maintainers mailing list<br>
<a href="mailto:Pkg-go-maintainers@lists.alioth.debian.org">Pkg-go-maintainers@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers" rel="noreferrer" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Best regards,<br>Michael</div>
</div>