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