On 14 April 2016 at 19:16, Michael Stapelberg <stapelb...@debian.org> wrote: > Thanks for the patch, it’s now merged and uploaded.
Awesome, thanks for that. > I’d prefer if you could send such patches in a bug report instead of to > mailing lists which I don’t actively read :). Noted! > In fact, I’d say it’s long overdue to make this package team-maintained. Sounds sensible. > The repository is already in > collab-maint, so if you want to make the necessary changes, please just go > ahead. I don't think I can commit to collab-maint (I'm not a DD or even a DM yet). Cheers, mwh > With regards to the original post, I think we have the same issue that the > haskell packaging community has, since they have the same linking model. > I’ve talked to Joachim Breitner (nomeata) about this a couple years ago and > he mentioned they have some tooling which addresses the issue in a > sufficient way. > > I’d suggest to tackle the problem the same way for Go, and maybe share some > tools if applicable. That said, I won’t have time or motivation to do any of > the work required for this, so volunteers are very welcome. > > On Thu, Apr 14, 2016 at 3:08 AM, Michael Hudson-Doyle > <michael.hud...@canonical.com> wrote: >> >> On 13 April 2016 at 21:05, Michael Hudson-Doyle >> <michael.hud...@canonical.com> wrote: >> > On 13 April 2016 at 17:07, Tianon Gravi <admwig...@gmail.com> wrote: >> >> On 12 April 2016 at 21:39, Michael Hudson-Doyle >> >> <michael.hud...@canonical.com> wrote: >> >>> We could do it without 1) and the consequent re-uploading of every go >> >>> library by using dpkg-query --search a lot, which would be slow I >> >>> guess, but maybe could be done as a fallback? >> >> >> >> I still asking dpkg about file/directory package ownership should be >> >> our primary means of generating this field -- the metadata that dpkg >> >> itself tracks about "which package provided >> >> /usr/share/gocode/src/abc/xyz which I just compiled against" will >> >> always be correct (due to the fact that it really is the single proper >> >> source of truth for such information), where some arbitrary metadata >> >> we add not only clutters up the package metadata as has been >> >> discussed, but much more importantly will have a tendency to "drift" >> >> from the truth, which is something that IMO we shouldn't tolerate for >> >> a field whose primary purpose is knowing when it's necessary to >> >> rebuild, especially for security fixes. Even for really large >> >> packages like Docker (to choose an example that I know off the top of >> >> my head is reasonably hefty WRT deps) we're only talking about maybe >> >> ~200 of these queries at the outside end, and only at build-time, and >> >> only once per build, which IMO is in the realm of reasonable to avoid >> >> yet again uploading a minor fix to every package (moving the metadata >> >> over to the binary packages when we still haven't added the existing >> >> source package metadata to all of them yet) with information that will >> >> have a potential for drifting from the truth or for being too limited >> >> (single package providing multiple namespaces after a repo move, for >> >> example). >> > >> > Yes, all that seems fair. Something like this? >> > http://paste.ubuntu.com/15806327/ -- it's pretty terrible perl, but >> > it's actually arguably simpler than what dh_golang does already! >> >> FWIW, I sent a better version of this patch: >> >> http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20160411/004304.html >> >> Cheers, >> mwh > > > > > -- > 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