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

[Michael Stapelberg]

Thinking about this some more, I think I now agree with the rationale.

When building packages, we must honor DH_GOLANG_EXCLUDES, so it doesn’t
make sense to have the source files in the package.

The next step is making sure that we can safely do this change without
breaking anything.

Clément, would you be interested in sending a patch and doing the test? If
not, can I suggest you file a bug for this issue, and I’ll pick it up when
time permits. Thanks!

On Thu, Feb 1, 2018 at 6:57 PM, Clément Hermann <nodens at nodens.org> wrote:

> On 23/01/2018 13:43, Martín Ferrari wrote:
> > On 22/01/18 16:57, Michael Stapelberg wrote:
> >
> >> 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.
> >
> > My rationale for that is that we ought to include them as examples (i.e.
> > in /usr/share/doc), and that many times, they do not build out of the
> > box, usually because of extra dependencies.
>
> >> 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.
> >
> > If they work, leaving them in the source and not excluding from
> > compilation/tests can be a good idea. And autopkgtest will pick them up
> > too. But I fear this will be a minority of cases.
>
> I agree that it can be useful to have the example, even in the source,
> in this case.
>
> But I think Martín is right, that's probably a small amount of packages.
>
> >
> >>     > 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.
> > The main issue that we discussed with Clément is that DH_GOLANG_EXCLUDES
> > excludes packages from compilation, but not from installation. And I
> > feel that is not the best outcome.
>
>
> Having a quick look using codesearch, I see that most package using
> DH_GOLANG_EXCLUDES leave them in the src tree afterward. A fair number
> of them apparently do what I did for golang-gopkg-lxc-go-lxc.v2, that is
> remove them from install afterward.
>
> An interesting counterexample is golang-github-prometheus-common, where
> it is explicitely said that what is exclude is installed via dh_install
> but excluded from compilation to avoid circular dep:
>
> https://sources.debian.org/src/golang-github-prometheus-
> common/0+git20180110.89604d1-1/debian/rules/?hl=8#L8
>
>
> I didn't go through all the packages, anyway as I suggested in the first
> mail it would be necessary to go through different stages to change
> this. Or we could simply add another var that would do both (but if we
> go that route, I still think the name is misleading because too generic,
> DH_GOLANG_BUILD_EXCLUDES or something like that would be clearer IMO).
>
> Cheers,
>
> --
> nodens
>
> _______________________________________________
> 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/20180215/d09e2830/attachment.html>