----- 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: Tuesday, February 6, 2018 7:34:03 PM
Subject: Re: Proposed Fedora packaging guideline: More Go packaging
----- Mail original -----
De: "Jakub Cajka"
>> 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.
My experience with humans is that they get attached to their bits of text
even when they have no time to finish them. But yes, I haven't tried, I
don't want to see a wiki page for a month after writing and formatting and
revising two separate packaging drafts.
> 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.
IMHO that's exactly what FPC expects: a quick start document, not an in-depth
encyclopædia. In-depth is too hardcore to be validated by domain laymen, is
useless to onboard new packagers (which is the primary objective of Fedora
guidelines), is never finished because the state of the art changes, and
can't be applied to check whether a spec is good or not because in-depth
concerns *complex* cases where the "right" choice is not obvious, depends on
many factors that change over time, and usually requires asking the domain
So you have the simple common cases, which are sufficient for most packagers,
and can be addressed by a formal document FPC can review and enforce, and
"other things" which are valuable but can not ever attain the formalness and
strictness level expected of Fedora guidelines, require continuous freedom
to edit, and are hosted in other Fedora wiki pages. At least that's how
real-life law is written (law text + expert commentaries) and how other
Fedora packaging SIGs function and got their guidelines approved.
> They are used primarily to minimize build root size, by reducing the deps
> size and code size.
Stripping example material from gopath installation filelists achieves the
same objective without all the complexity of managing packages that share
directories Go considers indivisible.
??, I have been talking about tests. From Go perspective source files and test source
file, testdata are two distinctive sets.
From my POV if your code depends for regular builds on tests code it means that there is
something horribly wrong with your project(regardless of language used).
Docs and examples would be great too, it should be in guidelines that packager must use
reasonable effort to create subpackages with them.
>> 7. even core Go people refuse to touch the subject with a 10 foot pole.
>> 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
>> Go understanding Sam Boyer Has.
> What has been demoed?? Unfortunately I could not make it there
Sam Boyer presented the current state of his go dep prototype, and explained
his design choices (for example no nested projects which means the go import
path root becomes a core concept and it's useless to invest in splitting
projects as that usually requires nesting). He ended up stating go dep will
ignore tests by default, tried to demo optional test handling, and that
failed. He had another conference the next day I couldn't get to as I was
stuck in another part of the campus.
Cool, there is recording for anyone interested
> Have you met with Jan there?
Unfortunately FOSDEM was its usual crazy stuff with multiple interesting
conferences at any given time and no hope of being admitted in a room if
you're late. So I've just been running from conf room to conf room without
any hope of meeting anyone :(
> Your packaging proposal seems fairly monolithic and disregarding any prior
> art, so extensions will be very painful.
Well, the creation of the proposal was a long suite of extending to cover
more cases (that's why some macros are rather long and convoluted), so I'm
quite sure extension is possible. Of course I may miss something, if you
identify a roadblock please point it out.
>> 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
That's pretty much how rpm prefers it to be (use %check and Builddeps) and
also how Go prefers it to be (no provision for splitting directories). Of
course anyone interested can try to fight the design of both of them to
achieve something else, and would try to help, but I'm not interested in
being this person.
>> > 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.
My maybe naïve POW is that shared libraries are just another container for
the elements currently installed in %gopath/src, so doing them is mostly
adding a separate stage in %build and making %goinstall install the result
instead of installing raw files.
The hardest part is to get compatible code bases, defining what needs
stripping in production, and defining shared libraries numbering.
The proposal helps for the two first points and I have no idea or opinion on
The rest is macro plumbing that should not require a lot of spec surgery once
specs are mostly free of custom shell code.
> 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.
API breakage is not a showstopper with the static linking Go prefers because
careful BuildDep construction can ensure only one (and the right one)
dependency code state ends up in the buildroot, and BuildDeps of the next
app can select another code state. So it's mostly a mater of creating the
necessary -devel compat packages and defining BuildDep constrains.
Not really, mostly with static linking you are fine if you change deps as long as you
don't touch basic runtime(glibc,...) and binaries will keep on working. In dynamic
linking when you change the deps in incompatible way(break API/ABI) you break the runtime
for all built binaries and you need to do rebuild to just keep distro working.
It is a showstopper for shared libs because you can't install several
versions of the same shared lib without separate identifiers/release ids to
disambiguate them, Go upstreams do not provide those identifiers today and I
doubt creating a Fedora-specific identifier namespace at the lib level would
be a good idea. Though, the few projects that version their import paths,
and make sure to only extend their APIS within a major release, could be
libified today (theoretically, I've not checked how to do it). I'm not sure
there are enough of them to be worth multiple packaging style
You can version the so's arbitrarily for example and have explicit non general require
on the devel, I think this really minor implementation detail from packaging discussion
> golang mailing list -- golang(a)lists.fedoraproject.org
> To unsubscribe send an email to golang-leave(a)lists.fedoraproject.org