[pkg-go] [RFC] honoring DH_GOLANG_EXCLUDES for sources ?

[Michael Stapelberg]

Sorry for the late reply. Answers inline:

On Mon, Jan 22, 2018 at 5:46 PM, Clément Hermann <nodens at nodens.org> wrote:

> Hi there,
>
> Ping / reminder about this RFC - since I didn't get any feedback ;)
>
> Cheers,
>
> nodens
>
> On 21/12/2017 21:05, Clément Hermann wrote:
> > Hi!
> >
> > I'm newly joined to the team, packaging some dependancies for LXD [0]
> > mainly.
> >
> > While working on golang-gopkg-lxc-go-lxc, Martin (Tincho) pointed to me
> > that I should exclude examples from source - which surprised me, because
>

We should exclude examples from being installed as binaries (which the
example below does), but it’s not clear to me why we would exclude them
from being included in the sources.

The advantage to having them installed is that they could be compiled when
testing packages for an updated package version, and thereby pinpointing an
issue more quickly. E.g., assume I’m updating golang-foo 2.2 to 2.3, which
is used by golang-bar, which in turn is used by cooltool. If golang-bar
comes with an example program, I might catch the issue which golang-foo 2.3
introduces as a failure in the golang-bar compilation, not only in the
cooltool compilation.

tincho, can you clarify the intention behind your advice?


> > I thought I did. But indeed, I misread the man page [1], which plainly
> > states that this is about excluding _targets_.
>

By “this”, you refer to DH_GOLANG_EXCLUDES, I assume.


> >
> > OTOH, the example debian/rule extract is:
> >
> >>
> >> # We want to ship only the library packages themselves, not the
> accompanying
> >>             # example binaries.
> >>             export DH_GOLANG_EXCLUDES := examples/
> >
> >
> > And in this case, we probably want to put the examples where they
> > belong, that is, in the documentation, not in the source.
> > So that mean we have to delete them from the source once they are copied.
> >
> > What if we didn't copy them in the first place ?
> >
> > I had a look at the code of dh-golang, and it wouldn't be difficult to
> > use the same logic we have in the configure sub in install.
> >
> > I actually started a branch to implement it.
> >
> >
> > Now the issue is dealing with this change (if it's indeed a change, it
> > could be an addition):
> >
> > - we could just decide to honor the excludes in install, at least for
> > sources and maybe bin. Then we have to deal with legacy, just in case,
> > so it should be possible to trigger it off, and at some point in the
> > future, we decide if it becomes the default or not.
> >
> > - we could just add another variable for sources, and maybe also for
> > bin. It looks counter-intuitive to me, but then it allows to deal with
> > the case when you want to exclude something from source but not from
> > target (regex problem, similar dir names in subdirs, etc).
> >
> > What do you think ?
> >
> > Cheers,
> >
>
>
> _______________________________________________
> 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/20180122/dc32d6a3/attachment.html>