----- Original Message -----
From: "nicolas mailhot"
Cc: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>, "Discussion of RPM packaging
standards and practices for Fedora" <packaging(a)lists.fedoraproject.org>
Sent: Monday, February 5, 2018 4:48:31 PM
Subject: Re: Proposed Fedora packaging guideline: More Go packaging
----- Mail original -----
De: "Jakub Cajka"
> 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
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
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
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
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
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
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
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
"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.
> Nicolas Mailhot
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org