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 [email protected] > 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
