----- 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. >> 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. > 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. 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 _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
