----- 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 protests.
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 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.
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
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
6. from what I've seen many of the existing test packages simply can not work because
they fail to include elements they need
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.
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).
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
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.
"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"