Re: [asmlib] - Library of optimized subroutines coded in assembly language.

Hi Andreas,

On Wed, Nov 5, 2014 at 7:45 PM, Andreas Tille <andreas@an3as.eu> wrote:

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.

Upstream for Debian means a temporary upstream placeholder to use for package building, whilst the KMC authors have a discussion with the asmlib author, to try to get him to distribute his code in a VCS manner.

If you look at [1], the code is distributed as a zip file that contains the compiled static libraries for several OS's and architectures. The source code is another zip file inside the original one. It contains a pdf plus other zip files. The source code itself uses a nmake makefile that performs cross compilation, through the use of yet another piece of code written by the author.

There is no versioning system whatsoever for asmlib. The author simply states that the most up to date version is always available in [1].

I do not see any point for not using straight upstream
repository.

I am hoping that the KMC authors will convince the asmlib author to distribute his code through a VCS.

It seems Git addicts have a lot of fun by cloning things.

I think you're assuming too much here.

In no way am I a git addict. My group uses git, I had never used git until I joined, but quite frankly I do like it. I think it's simple to work with.

And don't get me wrong, but I don't have much fun with any of this. I have fun surfing on a lovely beach with nice weather. This is nonetheless my job and I try to do it with enthusiasm.

In my view, if the upstream author sees the simplicity of what I have done, I believe it would be easier to convince him/her to use whatever VCS. In my case Git, because I am now used to it.

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.

I think this is explained above.

It makes more sense to me to have code distribution under a VCS.

Having spoken to Sascha just now, I understand that there are ways to go around this. I'll try to implement it today.

> [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

I have used it I think I just forgot to push it. It's now pushed for asmlib.

> 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.

Will push it in a while as this is not properly setup yet.

> [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!

At least something...

> 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.

I believe I stated the reasons for not using it above.

I'll work through quilt patches.

I only removed code to see if I could build the package in my machine.

And since the nmake makefile is completely useless with make + the only libraries useful for Debian would be the 32bit and and 64bit Unix libraries + I'm not making any changes to the original source file, simply adding a Unix Makefile, I thought this would be a simple solution.

> 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. :-)

Thanks, I had alreayd added d-shlibs as a dependency.

> "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.

This email was sent to both Debian Med and Debian Mentors. I thought it best to be as verbose as I could be.

> 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. ;-)

Maybe I'll just get someone to hit me with it senslessly.

Point taken.

Will do as you say.

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

Both have been done.

> Looking forward to all suggestions and if you need more information, please
> let me know.

Hope this helps

It helps. As always.

Regards,

Jorge