----- Original Message ----- > From: "Owen Taylor" <otaylor@xxxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Cc: golang@xxxxxxxxxxxxxxxxxxxxxxx, "Discussion of RPM packaging standards and practices for Fedora" > <packaging@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Wednesday, January 31, 2018 6:50:21 PM > Subject: Re: <DKIM> [Fedora-packaging] Re: Proposed Fedora packaging guideline: More Go packaging > > Hi Nicolas, > > Is there a guide for Fedora packagers about how to handle unbundling for > golang packages? The draft guidelines don't seem to go into any details. > I've looked at packaging a few golang packages unbundled, and have > immediately run into: > > A) lots of unpackaged dependencies > B) dependencies that are packaged in Fedora with different, often much older > versions > > A) is a pretty known quantity for any type of package, but I found B) more > intimidating. It seems like to package the new package, I have to get the > maintainer of the library to upgrade the version, and someone needs to > rebuild everything that depends on the rebuilt library and test that the > rebuilt packages work. > > Some tutorial showing a practical example of packaging a golang package for > the first time I think would be very helpful. > > Owen > Unfortunately this is how the situation stand thanks to the wide spread use of vendoring and generally no release and API stability in Go projects. You have to package all not packaged deps and work with other maintainers(which mostly means with Jan Chaloupka, cc'ed) to get other already packaged deps to commonly acceptable version/commit level, although it might not be even possible thanks to API breaks between commits. So you have to stick to bundling in some cases, if you really want to package that project. JC > > On Wed, Jan 31, 2018 at 5:30 AM, < nicolas.mailhot@xxxxxxxxxxx > wrote: > > > >De: "Neal Gompa" > > > The only thing I see that might be missing is autogenerating > > bundled(golang()) Provides when a vendor tree exists (with the > > appropriate automatic filters on Requires). > > I had though a little about doing it but first, as many Go elements, > vendoring relies on conventions not standards. The nasty thing about > conventions is that they are not applied 100% the same way by everyone, > making automation a PITA. And second interactions with autodeps can be > nasty: you can filter out provides, but do you filter out requires? What > about all the junk code many projects ship as testing and examples and which > is vendored with the rest? > > I don't say it can't be done, or that it would be difficult to do once the > rest is merged, but I'll live it to someone that absolutely want to ship a > Go package with vendored parts. > > Right now we sidestep the issue in our packages by rm -fr ing anything that > looks like vendored code in %prep. Unbundling takes time but it has a > positive cumulative effect: the more you unbundle the less you need to worry > about in other packages with the same requirements. And unbundling reveals > code/legal problems that it would take about as much work to solve by > auditing the vendored code manually. > > Regards, > > -- > Nicolas mAilhot > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > _______________________________________________ > 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
