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