[PATCH 31/41] gnu: Add go-github-com-google-shlex.

---

gnu/packages/golang.scm | 23 +++++++++++++++++++++++

1 file changed, 23 insertions(+)

merge 55903 56909 56914 56910 56911 56912 56913 56915 56916 56917 56918 56919 56920 56921 56922 56923 56924 56925 56926 56927 56928 56934 56930 56929 56931 56933 56936 56935 56932 56941 56938 56939 56937 56942 56940 56943 56944 56945 56946 56947 56948 56949

thanks

-- (

close 56909 56914 56910 56911 56912 56913 56915 56916 56917 56918 56919 56920 56921 56922 56923 56924 56925 56926 56927 56928 56934 56930 56929 56931 56933 56936 56935 56932 56941 56938 56939 56937 56942 56940 56943 56944 56945 56946 56947 56948 56949

thanks

-- (

unmerge 55903

thanks

-- (

close 56909 56914 56910 56911 56912 56913 56915 56916 56917 56918 56919 56920 56921 56922 56923 56924 56925 56926 56927 56928 56934 56930 56929 56931 56933 56936 56935 56932 56941 56938 56939 56937 56942 56940 56943 56944 56945 56946 56947 56948 56949

thanks

-- (

On 03-08-2022 14:04, ( via Guix-patches via wrote:

Can we just substitute* in the appropriate library reference or whatever

is the Go equivalent instead of propagating?  Maybe in in configList.go,

we can replace -lnotmuch by -l/gnu/store/.../libnotmuch.so or add a

-L/gnu/store/... there?

Why has the commit and description been changed since

https://issues.guix.gnu.org/37444? The change in synopsis seems good

to me though.

Also, there are multiple patches adding go-github-com-google-shlex now

-- as I've asked in the past, can we stop doing that, or at least add a

pointer to the previous version to avoid double work for reviewers?

Likewise for:

* https://issues.guix.gnu.org/search?query=go-google-golang-org-protobuf

* https://issues.guix.gnu.org/search?query=go-github-com-xo-terminfo

* https://issues.guix.gnu.org/search?query=go-github-com-go-ini-ini

* https://issues.guix.gnu.org/search?query=go-github-com-emersion-go-pgpmail

* [...]

Like, if I would properly review (including checking the source code)

this patch series and didn't know some of those were reviewed

previously, then I would have to do the review again even though that's

double work better spent elsewhere and if I later discover these were

actually reviewed previously, that doesn't sound good for motivation to me.

And even though I know some of those have been submitted and reviewed

previously, I don't remember which ones exactly and to which degree

(only superficial checks like checking synopsis, description and

#:tests?, or also source code checks, ...), so if I were to review this

(*), I would have to look up the old patches and reviews, see which ones

were reviewed previously and to what degree, look if changes have been

made (e.g. changing which commit to use) that invalidated the review,

..., which is not motivating to me.

(*) To be clear, I consider it unlikely for me to seriously review Go

stuff in the future, as the Go world is full of forks that make no

attempt to contribute back to upstream, or many independent

implementations (see e.g. terminfo and shlex) where a single or maybe

two implementations would suffice, often there's a lack of attempting

backwards compatibility and version numbers are often just 0.0.0, ...

Greetings,

Maxime.

On Wed Aug 3, 2022 at 4:38 PM BST, Maxime Devos wrote:

Good point! I'll try that.

I never referenced that issue in the making of this patchset :) I'll

change its description to that issue's version if you wish.

Maybe we could merge the patches adding those duplicate packages

standalone, without merging the other parts of the patchsets, so there

would be no need for anyone to write them again in the future.

I know what you mean. It's a huge pain.

-- (