On Sun, Nov 20, 2016 at 2:48 AM, Germano Massullo <germano.massullo@xxxxxxxxx> wrote: > We often deal with upstream developers that bundle libraries in their > code, so to make a package we have to debundle them, etc. > This time, an upstream dev. asked me what he could do to make easier > the work of packagers. > In this case the software is python-netjsongraph [1] that bundles > javascript-d3 library and that is being reviewd at [2] I've just gone through this with a developer who believed that the hand-built, hand-configured version of a library was better incorporated in the git repo for the source code for the rest of the package. It's mostly an education problem, to walk the developer thorugh the cross-compatibility and compilation programs inherent in embedding binaries into any source tree. And it's important to make the separation of "this library gets built from *this* repo and packaged as an RPM" distinct from bundling it for a different package,especially an RPM. It's an old problem. Samba and Subversion, which I've been involved with for years, both have this issue with their extensive reliance on libraries that may be considerably more recent than system libraries. > I think it would be nice to make a discussion even for non Python > packages, so we can elaborate a sort of vademecum that a packager > could show to upstreams when there is a collaboration between them. > > Have a nice day Most upstream developers are happy to work with segregating components. A few... such as the awscli python package manager..... use cfode with very bleeding edge and destabilizing dependencies. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
