Re: [asmlib] - Library of optimized subroutines coded in assembly language.
Hi Jorge,
On Wed, Nov 05, 2014 at 05:13:13PM +0000, Jorge Sebastião Soares wrote:
> Hi all,
>
> I have started packaging asmlib.
>
> [1] Original upstream - http://www.agner.org/optimize/
> [2] Upstream for Debian - https://github.com/js21/asmlib
What does that mean "upstream for Debian"? I admit this sounds really
suspicious. I do not see any point for not using straight upstream
repository. It seems Git addicts have a lot of fun by cloning things.
However, if you stop cloning from upstream and go on vacation for say
half a year we will not realise upstream changes since the master of
"our" clone is absent. This does not scale and I see no reason for
diverging from our usual procedure of operation.
> [3] Debian git - http://anonscm.debian.org/cgit/debian-med/asmlib.git/
> git+ssh://git.debian.org/git/debian-med/asmlib.git
It seems you missed using
git import-orig --pristine-tar
since the repository has no upstream branch. Please try to follow our
zeam policy as closely as possible. Otherwise your coworkers will have
trouble to
> This library will be a dependency of a future package that falls within the
> Debian Med remit.
> The package is called KMC.
>
> [4] Original upstream - http://sun.aei.polsl.pl/kmc/download.html
> [5] Upstream for Debian -https://github.com/js21/kmc
Same here.
> [6] Debian git - http://anonscm.debian.org/cgit/debian-med/kmc.git/
> git+ssh://git.debian.org/git/debian-med/kmc.git
>
> This in turn will be a dependency for the Virus Assembler (assembling as in
> genomes, not as in machine code) IVA written in python by a member of my
> team over at the Wellcome Trust Sanger Institute.
>
> [7] Original upstream - https://github.com/sanger-pathogens/iva
Sounds good!
> I am now at a point where I have the asmlib code stripped down to a bear
> minimum. You can see this in [2] and in [3]. It builds only for 64bit intel
> chips. I might add the 32bit code later in this packaging process.
? I can not parse this. Is there any reason not to use the upstream
code? If yes, please import the original source as released by upstream
and do everything else in quilt patches. If you need to strip anything
please do this with Files-Excluded in debian/copyright to make things
transparent for your coworkers. Removing code for certain architectures
at random which you add later on does not make any sense to me. Any
change on the original source code should be documented in
debian/README.source to let other people know and keep things
transparent for your co-workers.
> At the moment, the only file in the future asmlib package is libaelf64.a
> A collection of .o files.
> I am not experienced in c/c++. But this seems to me like a static library.
> Having had a look in [8],
Yes, that's a static library that belongs to the libasmlib-dev package.
You should also create a libasm<soversion> package containing a dynamic
library (*.so).
For packaging libraries compliant to [8] you are well advised to use
d-shlibs. We have several examples of its usage in Debian Med Git+SVN.
You used it yourself in your MoM training package. :-)
> "There are several reasons for providing static libraries, but it is best
> to avoid it, if it is technically possible"
>
> Would this constitute a lib package, would it constitute a lib-dev package?
Tha later contains *.h and *.a files.
> This library could be useful for several other developers and so the idea
> of packaging it together with KMC seems far from ideal and would make it
> hard to trace back to the original author.
Yes, for sure. I think the decision to package asmlib separately was
drawn in the beginning of this discussion.
> I need some guidance on how to proceed next.
As I said: Please stop relying on any clones but obtain plain upstream
release tarballs and inject them as described in our team policy which
you should put below your pillow. ;-)
If upstream does not provide information on how to create a dynamic
library you can
a) ask upstream themselves
b) ask on debian-mentors@l.d.o
> Looking forward to all suggestions and if you need more information, please
> let me know.
Hope this helps
Andreas.
> [8] -
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#staticonlylibs
--
http://fam-tille.de
Reply to: