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

[Michael Stapelberg]

As per
https://codesearch.debian.net/search?q=DH_GOLANG_EXCLUDES+path%3Adebian%2Frules=1,
currently 161 packages use DH_GOLANG_EXCLUDES.

On Thu, Feb 15, 2018 at 3:01 PM, Clément Hermann  wrote:

> Hi,
>
> On 15/02/2018 13:26, Michael Stapelberg wrote:
> > 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.
>
> Yes, and as I was saying in my first mail, it probably means having some
> kind of switch to make it non-default at first, or use another variable.
> That said, I intend to check how many packages use it: if it's only a
> handful of them.
> > 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!
> >
>
>
> I'll have a look, and file a bug if needed.
>
> Cheers,
>
> --
> nodens
>



-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Clément Hermann]

Hi,

On 15/02/2018 13:26, Michael Stapelberg wrote:
> 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.

Yes, and as I was saying in my first mail, it probably means having some
kind of switch to make it non-default at first, or use another variable.
That said, I intend to check how many packages use it: if it's only a
handful of them.
> 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!
> 


I'll have a look, and file a bug if needed.

Cheers,

-- 
nodens

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [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  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@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Martín Ferrari]

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 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.


-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [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  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@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Clément Hermann]

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
> I thought I did. But indeed, I misread the man page [1], which plainly
> states that this is about excluding _targets_.
> 
> 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@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Clément Hermann]

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
I thought I did. But indeed, I misread the man page [1], which plainly
states that this is about excluding _targets_.

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,

-- 
nodens

[0] https://bugs.debian.org/768073
[1] Debian::Debhelper::Buildsystem::golang(3pm)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers