----- Original Message ----- > From: "nicolas mailhot" <nicolas.mailhot@xxxxxxxxxxx> > To: golang@xxxxxxxxxxxxxxxxxxxxxxx > Cc: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx>, "Discussion of RPM packaging > standards and practices for Fedora" <packaging@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Monday, February 5, 2018 4:48:31 PM > Subject: Re: Proposed Fedora packaging guideline: More Go packaging > > > > ----- Mail original ----- > De: "Jakub Cajka" > > Hi Jakub > > > I think that it would be best if Nicolas could fold his proposal in to the > > original draft as > > optional part for simple library/binary packages. > > Frankly, that's a lot of work and churn, I don't want the new parts to be > refused because of something in the old parts, and I certainly do not want > to spend weeks replacing bits only to put them back in and so on while > people made up their mind on the things they want replaced or not. The new > parts are pretty much autonomous and complete, they are sufficient to create > working Fedora Go packages, they are ready for FPC review. > > If someone wants to extract the ready non discussion parts of the old page > and get them approved I can work with him to merge both elements > > I didn't want to write about the old page, but since you put it on the table. > > It is full of digressions and elements of no evident applied value while > packaging Go software. It's not an operational "how to do stuff" document > it's a "here are various things you may like to know about Go that may or > may not help you create Fedora Go packages, if they do not help you forget > about it and run gofed". There are too many WIP non operational bits in the > old pages to allow merging while in an approval process. And I'm sure any > attempt to strip the WIP bits from my side will be met with energetic > protests. Have you tried that? What make you assume that? I'm sure that if you do it in constructive way, they will be accepted. > > People, if you want that page to be ever approved by FPC make it more focused > and accurate. Remove anything that does not explain to a Fedora Go packager > how to write a Fedora Go spec file and what to ask upstream Go projects in a > Fedora packager role. And make sure what remains is succinct, easy to read, > and applicable without undocumented holes or gofed magic. I believe that technically exhausting document is needed as Go packaging is far from trivial. Sure it would be great to have (trivial) quick start guide. I think that your proposal fits that bill more than full documentation. > > I know that's a lot of non-fun work. I did this work on the new page. I don't > particularly *like* writing documentation. For every line I put in the new > page, I had to ask myself "is the value to the Fedora packager sufficient to > justify the time spend writing the text, formatting it, linking in the right > place, proofing the result". I didn't put in stuff I could not justify > cleaning up myself. If it was too much work to document it was either of > insufficient value or better automated rather than explained in a manual > process. > > Any part of the text that can not be finished or serves another role has no > place in a guideline submitted to FPC. It should be nuked or moved to a > separate wiki page. All the half-finished and non operational stuff in there > is the reason the draft has been stuck in pre-approval stage for four years. > Just put yourself in FPC's place, its mission is to confirm a guideline is > ready to be used by the average Fedora packager, not to produce it from > half-finished half-related messy notes of the domain experts. I believe I can see myself in their shoes(sure not 100% accurately) and I don't see anything that you are describing from their POV, it would be good to have the guidelines sooner, but I will have, as you, rather something complete than something half baked and semi broken. Please note that they are WIP and everybody is welcomed to contribute in constructive way. I don't think that there is any request for FPC to create the guidelines on their own and honestly it would rather bad idea IMHO. > > > As his proposal doesn't cover at least two major use cases, i.e. separate > > packaging of tests(they > > have no place in devel package as they artificially inflate build root > > size) > > At this point of time my mind is pretty much set. I won't do separate > packaging of tests because: > 1. that raises complex dependency handling questions > 2. the average Go project test code is full of crufty junk > 3. the average Go test depends on assets not tracked within Go > 4. Go is not designed to separate elements shipped in the same directory > 5. no one could answer when I asked the *three* Fedora lists what they were > using the existing test packages for They are used primarily to minimize build root size, by reducing the deps size and code size. > 6. from what I've seen many of the existing test packages simply can not work > because they fail to include elements they need Please file bugs or pull requests. We need to work together to improve the experience. I'm sure that you are including all the dependencies in your devel sub-package(that contain the tests) to be able to run them locally. > 7. even core Go people refuse to touch the subject with a 10 foot pole. Sam > Boyer tried to demo a very small part of what would be necessary this week > end at FOSDEM and this part of his demo *failed*. I don't have the level of > Go understanding Sam Boyer Has. What has been demoed?? Unfortunately I could not make it there. Have you met with Jan there? > > I am ready to work with people who want to make separate test packages and I > tried very hard to make them possible in the future but I won't spend time > trying to ship half-baked stuff that does not work and that no one has a > need for. > > The proposed patterns strip test code from devel packages so build root sizes > are safe (except for the original package build root, since I *do* execute > unit tests in check, and they pull their deps in the build root). Your packaging proposal seems fairly monolithic and disregarding any prior art, so extensions will be very painful. > > You want to test one of my packages, fine, just rebuild it. That will run > unit tests *and* build the project binaries (which are also a form of code > testing, and a very thorough one at that). I don't think that is great user experience nor packagers/maintainers experience. > > > and shipping pre-built shared libraries. > > The pre-build shared libraries the old guidelines refuse to build or > document? Why exactly are you stating it's a major use case, Fedora is not > doing it today. > ?? I'm bit confused. Yes, it is not mentioned there yet as Jan have been working on stabilizing APIs, so it will be feasible and added there. > "By default, the standard golang compiler produces static libraries. There is > little value in shipping these prebuilt, especially since these libraries > are very specifically tied to the exact minor release of the golang > compiler." > > "Presently the shared object libraries produced by GCC-Go are not usable" You have mentioned that the API breakage is not that big issue, so this led me to conclude that shared lib/bin packaging is now feasible. I believe that any Go packaging guideline that doesn't implement this side in working fashion is not FPC ready IMNHO. JC > > Regards, > > -- > Nicolas Mailhot > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
