> 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
, 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
> 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
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 p
Hi,
We needed to use pyBigWig for some of our processing.
https://pypi.python.org/pypi/pyBigWig/0.3.2 or
https://github.com/dpryan79/pyBigWig
Being able to read bigBed or bigWig and to be able to directly write
bigwig files seemed useful to us. The package is MIT/Expat licensed
I made
5 matches
Mail list logo
