Re: pyBigWig

2016-12-02 Thread Diane Trout

> I am not quite sure what you mean by "organizing the source tree",
> since 
> you are supposed to have the unpacked sources from the upstream
> tarball, 
> plus an additional debian/ folder containing the Debian specific
> files 
> (control, copyright, rules...). This is common to all packaging
> policies.

That was perhaps an awkward phrase. But what I meant was I used to
doing git buildpackage style packages, but I was trying to make this
package's repository git-dpm compatible.


The Python Modules team is currently recommending git-dpm, and there's
some extra configuration they suggested. 

https://wiki.debian.org/Python/GitPackaging#Tag_style


Diane



Re: pyBigWig

2016-12-02 Thread Ghislain Vaillant

On 02/12/16 19:14, Diane Trout wrote:



I don't think this is a problem. Policy 4.13 [1] says

~~~
Debian packages should not make use of these convenience copies
unless
the included package is explicitly intended to be used in this way.
~~~

which I think matches the situation here.


Thank you for point that clause out.

As its a python module I followed python team conventions for
organizing the source tree. But it seems like the package really should
be under debian-med? Is that OK?

Diane


There is a large range of Python packages being maintained in other 
teams than the DPMT, and the latter usually recommends to follow the 
Python packaging recommendations.


In the end, where the package (pyBigWig) is hosted becomes a matter of 
choice for the maintainer (yourself) and the decision is often based on 
which team is likely to be more able to assist with looking after the 
package long-term. For instance, if pyBigWig is mostly used by other 
d-med packages, then it is sensible to host it alongside them.


I am not quite sure what you mean by "organizing the source tree", since 
you are supposed to have the unpacked sources from the upstream tarball, 
plus an additional debian/ folder containing the Debian specific files 
(control, copyright, rules...). This is common to all packaging policies.


Ghis



Re: pyBigWig

2016-12-02 Thread Diane Trout

> I don't think this is a problem. Policy 4.13 [1] says
> 
> ~~~
> Debian packages should not make use of these convenience copies
> unless
> the included package is explicitly intended to be used in this way.
> ~~~
> 
> which I think matches the situation here.

Thank you for point that clause out.

As its a python module I followed python team conventions for
organizing the source tree. But it seems like the package really should
be under debian-med? Is that OK?

Diane



Re: pyBigWig

2016-12-01 Thread Afif Elghraoui
Hello,

على الخميس  1 كانون الأول 2016 ‫16:32، كتب Diane Trout:
> And instead of building a shared library, they just add the C files to
> the python C extension. See:
> https://github.com/dpryan79/pyBigWig/blob/master/setup.py#L14
> 
> I believe this is a violation of Debian packaging policy, but this
> seems useful, what should one do in this case?

I don't think this is a problem. Policy 4.13 [1] says

~~~
Debian packages should not make use of these convenience copies unless
the included package is explicitly intended to be used in this way.
~~~

which I think matches the situation here.

Thanks and regards
Afif

1. https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name