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@xxxxxxxxxxxxxxxx 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
