----- 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: Tuesday, February 6, 2018 7:34:03 PM > Subject: Re: Proposed Fedora packaging guideline: More Go packaging > > > > ----- Mail original ----- > De: "Jakub Cajka" > > Hi Jakub, > > >> 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. > > 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 > 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 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. > >> 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 > > 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 https://fosdem.org/2018/schedule/event/dep/. > > > 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 > > experience. > > 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 > > 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 > > Regards, > > -- > Nicolas Mailhot 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 POV. JC > _______________________________________________ > golang mailing list -- golang@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to golang-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
