9:31 p.m.
Hi!
Numerous Golang packages are plagued with an issue caused when jchaloup uploaded Glide
files. In a lot of case he has doubled the glide.yaml instead of adding the qlide.lock:
Source1: glide.yaml
Source2: glide.yaml
The problem is that when goinstall doesn't find the glide.lock file:
%goinstall glide.lock glide.yaml
it creates a folder instead.
Now when we try to fix the problem by re-adding the glide.lock file to the Sources, we are
asking RPM to replace a folder by a file at update time, which it refuses to do so to
avoid losing data the user might have placed there.
We get errors like:
Error: Transaction check error:
file /usr/share/gocode/src/github.com/mitchellh/go-homedir/glide.lock from install of
golang-github-mitchellh-go-homedir-devel-1.1.0-1.fc29.noarch conflicts with file from
package golang-github-mitchellh-go-homedir-devel-0-0.10.20180708gitdf55a15.fc29.noarch
This is a PITA. the only workaround it to add a %pretrans lua macro to deal with the
mess.
# Remove in F33
# Remove erroneous glide.lock folder
%pretrans devel -p <lua>
path = "%{gopath}/src/%{goipath}/glide.lock"
st = posix.stat(path)
if st and st.type == "directory" then
os.remove(path)
end
See
https://fedoraproject.org/wiki/Packaging:Directory_Replacement#Scriptlet_...
I have no idea how many packages are affected. But it's more work on our already full
plates.
Best regards,
Robert-André
3:29 a.m.
New subject: Deciding on Fedora Go (Golang) packaging future
Le dimanche 17 mars 2019 à 03:31 +0100, Robert-André Mauchin a écrit :
Hi,
Numerous Golang packages are plagued with an issue caused when
jchaloup uploaded Glide files. In a lot of case he has doubled the
glide.yaml instead of adding the qlide.lock:
Source1: glide.yaml
Source2: glide.yaml
The problem is that when goinstall doesn't find the glide.lock file:
%goinstall glide.lock glide.yaml
The fix to avoid creating things that do not exist just because the
packager specified them explicitly in its spec has been written for a
month¹:
https://pagure.io/go-rpm-macros/c/73222d467d9e95e9281a6c37d4b5808b118bde9b
Like all the fixes that accumulated in golist and in go macros for a
year, it is waiting for the Go SIG to decide what it wants to do with
its packaging tooling. Waiting for jchaloup to change things on his own
authority without asking anyone does not work anymore².
***********************************************************************
It would be really nice if a sufficient number of Fedora Go packagers
attended the next SIG meeting so we have the quorum to decide what to
do, find volunteers to do the necessary work, and mandate them to do
this work.
***********************************************************************
The next meeting is scheduled in three days on 2019-03-20 from
16:00:00 to 17:00:00 UTC at fedora-golang(a)irc.freenode.net
Of course some packagers are more equal than others, so whatever the
quorum I can't imagine anything going forward without the approval and
support of the Fedora golang maintainer.
Right now we have one proposal on the table:
https://pagure.io/GoSIG/go-sig/issue/20
People are free to write up their own alternative, either a variation
on this plan or something else entirely. Remember, any plan is
worthless if no one volonteers to implement it. So "someone (else)
should do things" and no one wants to do it won't take us anywhere.
The key weakness of my plan is that it only considers short-term
existing problems, upstream has stated it will switch on Go modules by
default in August, and that will change Go packaging a lot. My
preference would be to fix what we have before engaging in a Go module
journey, but an alternative would be keep things as they are (bugs
included) and just dump the existing packaging code to replace it with
*something else* at Go module time (big bang approach).
However, if the *something else* is written by me, it is likely to
require pretty much the same tooling setup and spec syntax as proposed
in my plan (replacing golist with something module-oriented).
Regards,
¹ Of course it will not fix the consequences of past errors, just
prevent new ones
² And, jchaloup had facilities others do not have (working @rh, trusted
by the Fedora golang maintainer, owning many key packages).
--
Nicolas Mailhot
9:36 a.m.
New subject: Deciding on Fedora Go (Golang) packaging future
On dimanche 17 mars 2019 09:29:28 CET Nicolas Mailhot wrote:
Le dimanche 17 mars 2019 à 03:31 +0100, Robert-André Mauchin a écrit
:
Hi,
>
> Numerous Golang packages are plagued with an issue caused when
> jchaloup uploaded Glide files. In a lot of case he has doubled the
> glide.yaml instead of adding the qlide.lock:
>
> Source1: glide.yaml
> Source2: glide.yaml
>
> The problem is that when goinstall doesn't find the glide.lock file:
>
>
> %goinstall glide.lock glide.yaml
The fix to avoid creating things that do not exist just because the
packager specified them explicitly in its spec has been written for a
month¹:
https://pagure.io/go-rpm-macros/c/73222d467d9e95e9281a6c37d4b5808b118bde9b
Like all the fixes that accumulated in golist and in go macros for a
year, it is waiting for the Go SIG to decide what it wants to do with
its packaging tooling. Waiting for jchaloup to change things on his own
authority without asking anyone does not work anymore².
***********************************************************************
It would be really nice if a sufficient number of Fedora Go packagers
attended the next SIG meeting so we have the quorum to decide what to
do, find volunteers to do the necessary work, and mandate them to do
this work.
***********************************************************************
The next meeting is scheduled in three days on 2019-03-20 from
16:00:00 to 17:00:00 UTC at fedora-golang(a)irc.freenode.net
Of course some packagers are more equal than others, so whatever the
quorum I can't imagine anything going forward without the approval and
support of the Fedora golang maintainer.
Right now we have one proposal on the table:
https://pagure.io/GoSIG/go-sig/issue/20
People are free to write up their own alternative, either a variation
on this plan or something else entirely. Remember, any plan is
worthless if no one volonteers to implement it. So "someone (else)
should do things" and no one wants to do it won't take us anywhere.
The key weakness of my plan is that it only considers short-term
existing problems, upstream has stated it will switch on Go modules by
default in August, and that will change Go packaging a lot. My
preference would be to fix what we have before engaging in a Go module
journey, but an alternative would be keep things as they are (bugs
included) and just dump the existing packaging code to replace it with
*something else* at Go module time (big bang approach).
However, if the *something else* is written by me, it is likely to
require pretty much the same tooling setup and spec syntax as proposed
in my plan (replacing golist with something module-oriented).
Regards,
¹ Of course it will not fix the consequences of past errors, just
prevent new ones
² And, jchaloup had facilities others do not have (working @rh, trusted
by the Fedora golang maintainer, owning many key packages).
--
Nicolas Mailhot
The issue seems to hinge or writing new Go guidelines for the new macros, he
example SPECs could be a part of that but not the only source.
3:41 a.m.
New subject: Deciding on Fedora Go (Golang) packaging future
----- Original Message -----
From: "Robert-André Mauchin" <zebob.m(a)gmail.com>
To: golang(a)lists.fedoraproject.org
Sent: Sunday, March 17, 2019 3:36:47 PM
Subject: Re: Deciding on Fedora Go (Golang) packaging future
On dimanche 17 mars 2019 09:29:28 CET Nicolas Mailhot wrote:
> Le dimanche 17 mars 2019 à 03:31 +0100, Robert-André Mauchin a écrit :
> Hi,
>
> >
> > Numerous Golang packages are plagued with an issue caused when
> > jchaloup uploaded Glide files. In a lot of case he has doubled the
> > glide.yaml instead of adding the qlide.lock:
> >
> > Source1: glide.yaml
> > Source2: glide.yaml
> >
> > The problem is that when goinstall doesn't find the glide.lock file:
> >
> >
> > %goinstall glide.lock glide.yaml
>
>
> The fix to avoid creating things that do not exist just because the
> packager specified them explicitly in its spec has been written for a
> month¹:
> https://pagure.io/go-rpm-macros/c/73222d467d9e95e9281a6c37d4b5808b118bde9b
>
> Like all the fixes that accumulated in golist and in go macros for a
> year, it is waiting for the Go SIG to decide what it wants to do with
> its packaging tooling. Waiting for jchaloup to change things on his own
> authority without asking anyone does not work anymore².
>
> ***********************************************************************
> It would be really nice if a sufficient number of Fedora Go packagers
> attended the next SIG meeting so we have the quorum to decide what to
> do, find volunteers to do the necessary work, and mandate them to do
> this work.
> ***********************************************************************
>
> The next meeting is scheduled in three days on 2019-03-20 from
> 16:00:00 to 17:00:00 UTC at fedora-golang(a)irc.freenode.net
>
> Of course some packagers are more equal than others, so whatever the
> quorum I can't imagine anything going forward without the approval and
> support of the Fedora golang maintainer.
>
> Right now we have one proposal on the table:
> https://pagure.io/GoSIG/go-sig/issue/20
>
> People are free to write up their own alternative, either a variation
> on this plan or something else entirely. Remember, any plan is
> worthless if no one volonteers to implement it. So "someone (else)
> should do things" and no one wants to do it won't take us anywhere.
>
> The key weakness of my plan is that it only considers short-term
> existing problems, upstream has stated it will switch on Go modules by
> default in August, and that will change Go packaging a lot. My
> preference would be to fix what we have before engaging in a Go module
> journey, but an alternative would be keep things as they are (bugs
> included) and just dump the existing packaging code to replace it with
> *something else* at Go module time (big bang approach).
>
> However, if the *something else* is written by me, it is likely to
> require pretty much the same tooling setup and spec syntax as proposed
> in my plan (replacing golist with something module-oriented).
>
> Regards,
>
>
> ¹ Of course it will not fix the consequences of past errors, just
> prevent new ones
>
> ² And, jchaloup had facilities others do not have (working @rh, trusted
> by the Fedora golang maintainer, owning many key packages).
>
> --
> Nicolas Mailhot
The issue seems to hinge or writing new Go guidelines for the new macros, he
example SPECs could be a part of that but not the only source.
Precisely, that is my main issue. Whenever I have brought this up with Nicolas, I have
been told that he is not going to do such a thing as it is useless and it will require
significant effort. I can agree only with the latter. As long there is no (draft of)
policy and user/packager facing documentation and Nicolas is effectively only person that
understands how the new macros work and he doesn't want to share this knowledge with
wide public. I can't endorse them in anyway and I will dare to say they are not fit
for Fedora in anyway until this crucial part is added.
And as Nicolas is pointing out he will probably have to take ownership of all the
dependencies of his macros. Golist exist based on Nicolas's initial requests and
requirements(created based on them by jchaloupka in his free time over one year ago), if
they have shifted he will probably need to change/implement the tools that he needs as
unfortunately Jan doesn't have free time that he could dedicate to Fedora anymore(or
at least it seems so).
Lastly I believe that this official change of macros will require official "System
wide change proposal" filed as it affects literally every Go package in Fedora,
regardless if it will get SIG's(or anyone's) endorsement.
Looking forward to see you all on the next SIG meeting.
JC
>
> _______________________________________________
> golang mailing list -- golang(a)lists.fedoraproject.org
> To unsubscribe send an email to golang-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org
>
3:55 a.m.
New subject: Deciding on Fedora Go (Golang) packaging future
----- Original Message -----
From: "Robert-André Mauchin" <zebob.m(a)gmail.com>
To: golang(a)lists.fedoraproject.org
Sent: Sunday, March 17, 2019 3:36:47 PM
Subject: Re: Deciding on Fedora Go (Golang) packaging future
On dimanche 17 mars 2019 09:29:28 CET Nicolas Mailhot wrote:
> Le dimanche 17 mars 2019 à 03:31 +0100, Robert-André Mauchin a écrit :
> Hi,
>
> >
> > Numerous Golang packages are plagued with an issue caused when
> > jchaloup uploaded Glide files. In a lot of case he has doubled the
> > glide.yaml instead of adding the qlide.lock:
> >
> > Source1: glide.yaml
> > Source2: glide.yaml
> >
> > The problem is that when goinstall doesn't find the glide.lock file:
> >
> >
> > %goinstall glide.lock glide.yaml
>
>
> The fix to avoid creating things that do not exist just because the
> packager specified them explicitly in its spec has been written for a
> month¹:
> https://pagure.io/go-rpm-macros/c/73222d467d9e95e9281a6c37d4b5808b118bde9b
>
> Like all the fixes that accumulated in golist and in go macros for a
> year, it is waiting for the Go SIG to decide what it wants to do with
> its packaging tooling. Waiting for jchaloup to change things on his own
> authority without asking anyone does not work anymore².
>
> ***********************************************************************
> It would be really nice if a sufficient number of Fedora Go packagers
> attended the next SIG meeting so we have the quorum to decide what to
> do, find volunteers to do the necessary work, and mandate them to do
> this work.
> ***********************************************************************
>
> The next meeting is scheduled in three days on 2019-03-20 from
> 16:00:00 to 17:00:00 UTC at fedora-golang(a)irc.freenode.net
>
> Of course some packagers are more equal than others, so whatever the
> quorum I can't imagine anything going forward without the approval and
> support of the Fedora golang maintainer.
>
> Right now we have one proposal on the table:
> https://pagure.io/GoSIG/go-sig/issue/20
>
> People are free to write up their own alternative, either a variation
> on this plan or something else entirely. Remember, any plan is
> worthless if no one volonteers to implement it. So "someone (else)
> should do things" and no one wants to do it won't take us anywhere.
>
> The key weakness of my plan is that it only considers short-term
> existing problems, upstream has stated it will switch on Go modules by
> default in August, and that will change Go packaging a lot. My
> preference would be to fix what we have before engaging in a Go module
> journey, but an alternative would be keep things as they are (bugs
> included) and just dump the existing packaging code to replace it with
> *something else* at Go module time (big bang approach).
>
> However, if the *something else* is written by me, it is likely to
> require pretty much the same tooling setup and spec syntax as proposed
> in my plan (replacing golist with something module-oriented).
>
> Regards,
>
>
> ¹ Of course it will not fix the consequences of past errors, just
> prevent new ones
>
> ² And, jchaloup had facilities others do not have (working @rh, trusted
> by the Fedora golang maintainer, owning many key packages).
>
> --
> Nicolas Mailhot
The issue seems to hinge or writing new Go guidelines for the new macros, he
example SPECs could be a part of that but not the only source.
Precisely, that is my main issue. Whenever I have brought this up with Nicolas, I have
been told that he is not going to do such a thing as it is useless and it will require
significant effort. I can agree only with the latter. As long there is no (draft of)
policy and user/packager facing documentation and Nicolas is effectively only person that
understands how the new macros work and he doesn't want to share this knowledge with
wide public. I can't endorse them in anyway and I will dare to say they are not fit
for Fedora in anyway until this crucial part is added.
And as Nicolas is pointing out he will probably have to take ownership of all the
dependencies of his macros. Golist exist based on Nicolas's initial requests and
requirements(created based on them by jchaloupka in his free time over one year ago), if
they have shifted he will probably need to change/implement the tools that he needs as
unfortunately Jan doesn't have free time that he could dedicate to Fedora anymore(or
at least it seems so).
Lastly I believe that this official change of macros will require official "System
wide change proposal" filed as it affects literally every Go package in Fedora,
regardless if it will get SIG's(or anyone's) endorsement.
Looking forward to see you all on the next SIG meeting.
JC
PS: CC'ed also Fedora's devel as the initial post did
>
> _______________________________________________
> golang mailing list -- golang(a)lists.fedoraproject.org
> To unsubscribe send an email to golang-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/golang@lists.fedoraproject.org
>
2:58 p.m.
New subject: Deciding on Fedora Go (Golang) packaging future
Le lundi 18 mars 2019 à 04:55 -0400, Jakub Cajka a écrit :
Hi,
Golist exist based
on Nicolas's initial requests and requirements(created based on them
by jchaloupka in his free time over one year ago),
This is quite a simplistic way to present things, which is injust to
Jan and to me.
I wished to make Go packaging in Fedora less a manual shore. I wrote
some shell and lua code to do it. You (and Jan) objected to this code
and asked me to restructure it around golist. Jan had already written
most of golist to analyse the Go code he dealt with (not just in an rpm
context).
golist is very much Jan's project and design. We collaborated: Jan
adapted his code so I could plug it within my rpm automation, just like
I adapted my code around the golist design.
Some things were indeed added to golist at my request. But, there are
lots of things in golist I never asked for: some I didn't think of,
some I had no need of, some I disagreed with, some that made my life a
lot harder than it should have been rpm macro-side.
And, Jan could probably say the same things about my rpm shell+lua
macro code.
So, to give everyone's his due, the Fedora rpm macro code is my work
and design, with some collaboration by Jan, and the golist code is
Jan's work and design, with some collaboration by me.
We definitely didn't always agree or approve the design decisions the
other made. We made do with those disagreements, which is how things
can move forward in a team.
Best regards,
--
Nicolas Mailhot
7:33 a.m.
New subject: Deciding on Fedora Go (Golang) packaging future
----- Original Message -----
From: "Nicolas Mailhot"
<nicolas.mailhot(a)laposte.net>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>, golang(a)lists.fedoraproject.org
Sent: Monday, March 18, 2019 8:58:39 PM
Subject: Re: Deciding on Fedora Go (Golang) packaging future
Le lundi 18 mars 2019 à 04:55 -0400, Jakub Cajka a écrit :
Hi,
> Golist exist based
> on Nicolas's initial requests and requirements(created based on them
> by jchaloupka in his free time over one year ago),
This is quite a simplistic way to present things, which is injust to
Jan and to me.
I wished to make Go packaging in Fedora less a manual shore. I wrote
some shell and lua code to do it. You (and Jan) objected to this code
and asked me to restructure it around golist. Jan had already written
most of golist to analyse the Go code he dealt with (not just in an rpm
context).
golist is very much Jan's project and design. We collaborated: Jan
adapted his code so I could plug it within my rpm automation, just like
I adapted my code around the golist design.
Some things were indeed added to golist at my request. But, there are
lots of things in golist I never asked for: some I didn't think of,
some I had no need of, some I disagreed with, some that made my life a
lot harder than it should have been rpm macro-side.
And, Jan could probably say the same things about my rpm shell+lua
macro code.
So, to give everyone's his due, the Fedora rpm macro code is my work
and design, with some collaboration by Jan, and the golist code is
Jan's work and design, with some collaboration by me.
We definitely didn't always agree or approve the design decisions the
other made. We made do with those disagreements, which is how things
can move forward in a team.
Best regards,
--
Nicolas Mailhot
Yes this is what I have been trying to convey, sorry that is wasn't obvious(although I
have consciously omitted that something similar is part of Gofed as it is IMHO not
relevant in this context). As you wrote golist that is part of the Fedora is there based
on your request and requirements. If you have not requested it, it wouldn't been
there/here.
JC
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
1857
days inactive
1859
days old
golang@lists.fedoraproject.org
6 comments
3 participants
participants (3)
-
Jakub Cajka -
Nicolas Mailhot -
Robert-André Mauchin