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
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
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
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
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
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo