upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

[Germano Massullo]

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 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


[1]: https://github.com/interop-dev/django-netjsongraph
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1369213

[Zbigniew Jędrzejewski-Szmek]

On Sun, Nov 20, 2016 at 08:48:27AM +0100, Germano Massullo 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 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. 
I think it comes down to:
- don't bundle,
- if you have to bundle, provide an easy and unambiguous configure switch
  to use the system version of the dependency,
- never, never, patch stuff in-tree.

Zbyszek

[Link Dupont]

On Sun, 2016-11-20 at 15:42 +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  I think it comes down to:
>  - don't bundle,
>  - if you have to bundle, provide an easy and unambiguous configure
>  switch
>    to use the system version of the dependency,
>  - never, never, patch stuff in-tree. 
- Don't hard-code paths (respect things like CMake's GNUInstallDirs).
- Strongly consider using a configure/build system (autotools, cmake,
ninja, etc.)

[Nico Kadel-Garcia]

On Sun, Nov 20, 2016 at 2:48 AM, Germano Massullo
<germano.massullo(a)gmail.com&gt; 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.

[Germano Massullo]

Il 20/11/2016 21:38, Nico Kadel-Garcia ha scritto:
> > 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. 
Ok, concerning [1][2] (Python+ JavaScript), what would you suggest to
the upstream (Federico Capoano), in order to make the work easier for
both us and him?
Thank you

[1]: https://github.com/interop-dev/django-netjsongraph
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1369213

[Germano Massullo]

Il 20/11/2016 21:38, Nico Kadel-Garcia ha scritto:
> > 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. 
Ok, concerning [1][2] (Python+ JavaScript), what would you suggest to
the upstream (Federico Capoano), in order to make the work easier for
both us and him?
Thank you

[1]: https://github.com/interop-dev/django-netjsongraph
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1369213

[Pete Travis]

On Nov 20, 2016 1:49 AM, "Germano Massullo" <germano.massullo(a)gmail.com&gt;
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 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
>
>
>  [1]: https://github.com/interop-dev/django-netjsongraph
>  [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1369213 
For Python packages, my biggest complaint is when versioned dependencies
are explicitly declared without due diligence.  Rough example: Upstream
foobar developer gets foo-24.2 from pip, sets foo == 24.2 in their
requirements.  Fedora currently packages foo-21.8; foo usage doesn't change
for 18.0 < foo < 34.0 .  Add in 1-12 other dependencies, and I'm doing a
lot more manual work when updating foobar because upstream's declared
requirements simply are not useful in a distribution packaging context.

-- Pete