You are not logged in.

#1 2016-03-26 23:35:45

alexei
Member
Registered: 2013-12-21
Posts: 5

Guidelines on packaging upstream with vendored dependencies

Vendoring dependencies (copying into application source) seems to be fashionable these days (for example, Go-lang crew is explicitly recommending doing this, some Python apps I'm working with do this too). This practice is at odds with distributions for straightforward reasons. What are the guidelines? and are there examples in the community repo or AUR? Example in contex of Python would be good.

Should the PKGBUILD patch the upstream to make it not use the dependencies it has vendored? This is doable, but (1) is often not a trivial patch, (2) creates patches to maintain, (3) does not solve the problem when upstream has patched a dependency (that's the nastiest of all)?

Also, please share your thoughts on this problem in general. Thanks.

Offline

#2 2016-03-26 23:44:05

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,559

Re: Guidelines on packaging upstream with vendored dependencies

If you're talking about bundled libs, Arch usually tries to remove them if possible.

Offline

#3 2016-03-27 02:17:19

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Guidelines on packaging upstream with vendored dependencies

Generally they are removed.

python-setuptools from extra uses a de-vendored copy of python-packaging. This is not too hard as the upstream source supports doing so simply by removing the "_vendor" directory.
Or on the other hand calibre, which contains several vendored python libs, patches them to fix unresolved upstream bugs (#3) -- plus one outright fork. calibre inserts its own vendored+internal libs into sys.path so simply removing them is once again good enough to fallback on the system installation (not that this is necessarily a good idea though). I have a still-open bug report asking for them to be reincluded in the Arch package...

I would de-vendor things that don't break the package, if it is simple to do, but I would rather ask upstream to do it.
Working software is still the priority though.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

Board footer

Powered by FluxBB