----- 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
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 experts directly.
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
> 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
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.
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
> 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
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 third.
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
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
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