Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
On 21 November 2016 at 21:49, Neal Gompa wrote: > On Mon, Nov 21, 2016 at 4:42 AM, Piotr Ozarowski wrote: >> In Debian we have https://wiki.debian.org/UpstreamGuide >> I guess more official, cross-distro document that we all point upstream >> authors to would be a nice idea as well. > > It would be a great idea if there were principles that all > distributions could agree on and have a document codify that so that > all distributions can reference it to upstream. Donald Stufft laid out the Python upstream position in https://caremad.io/posts/2013/07/setup-vs-requirement/ The gist is that for abstract dependencies (e.g. setup.py), we want people to specify the cases that they know *don't* work: - minimum versions - maximum versions if there's a particular known breaking change, or if a particular dependency is well-known for API breaks - exclusions for known incompatibilities with particular versions This is useful information for both end users and redistributors, as it indicates the versions of dependencies that upstream will flat out refuse to support. By contrast, concrete dependencies (e.g. requirements.txt) are intended for deployment rather than redistribution, and hence can (and usually should) pin the exact combination of dependencies that was tested. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
On Mon, Nov 21, 2016 at 4:42 AM, Piotr Ozarowski wrote: > Hi, > > [Germano Massullo, 2016-11-20] >> 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. > > In Debian we have https://wiki.debian.org/UpstreamGuide > I guess more official, cross-distro document that we all point upstream > authors to would be a nice idea as well. It would be a great idea if there were principles that all distributions could agree on and have a document codify that so that all distributions can reference it to upstream. -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
On Nov 20, 2016 1:49 AM, "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. > > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
On Sun, Nov 20, 2016 at 2:48 AM, 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'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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
On Sun, 2016-11-20 at 15:42 +, 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.) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org