[MoM] Re: kmer-tools
Hi Afif,
On Mon, May 04, 2015 at 07:00:20PM -0700, Afif Elghraoui wrote:
> >Well, if you have strong reasons like these I will not stop you from
> >modularising the packaging. If there are good chances that users might
> >want to use only parts of kmer - than my hint was possibly not the best
> >(since I do not know the source). Please do whatever you consider
> >sensible from a users point of view. It was just unusual to what we
> >are usually doing - but not necessarily wrong in this specific case.
>
> Yes, some of these tools are described in their own scientific
> publications.
This makes a good point for modularisation in principle. But as said
before we might delay this to some later point in time (at your
preference). Regarding publications: Would you mind adding them in
a debian/upstream/metadata file? Here is an example how you can
specify more than one publication:
https://anonscm.debian.org/viewvc/debian-med/trunk/packages/rostlab/disulfinder/trunk/debian/upstream/metadata?view=markup
Here you can find the definition of the format:
https://wiki.debian.org/UpstreamMetadata
The idea behind specifying publications is to do upstream some favour
(that they deserve anyway) and by doing so making them more willing to
cooperate with us. You can see lots of such citations on the Debian Med
tasks pages and by simply adding these metadata it will be displayed
there.
In your specific situation it might be important to note that currently
we only display *one* publication per *binary package*. So from this
point of view it might really make sense to split up the package
(later).
> I think this is part of the reason why upstream does
> not assign one version number to cover all the components.
Since it might take to long to teach upstream about proper
modularisation I guess it is best to adapt on the situation as is.
> >>But
> >>you're right, I think it's not worth all the extra bugs that will
> >>undoubtedly come out of it.
> >
> >You are right that there is a chance of missing dependency relations.
> >May be you simply keep your original idea in mind for some later point
> >in time and concentrate on getting something out for your final target
> >first.
>
> I think this is a reasonable approach.
OK.
> >>Sounds good. What could the <soversion> be? I have a svn snapshot--
> >>can I use what I have for the package version?
> >
> >No, definitely not the package version. Its a sad fact that several
> >upstreams have no idea about this. Please have a look at
> >
> >https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi
> >
> >Does this answer your question?
>
> I just thought it was strange to have one library package for
> several loosely-coupled/possibly independent libraries.
Sometimes we need to make some compromise to work with the situation as
is. I think it is not much harm done for packages that will admittedly
not find a lot of users. So we should try our best to get it clean but
not more (like becoming upstream of the software we are packaging).
> >May be we might go without any soname
> >versioning since there seem to be several libraries bundled and we can
> >not trust upstream to change their ABI compatibility in the same manner.
>
> I think this makes sense.
OK.
> >>No, I was actually going to ask about this-- there are no official
> >>upstream releases, so there's no original tarball. I took the
> >>snapshot of the svn repository from sourceforge, which came to me as
> >>a zip-file. I unzipped it and then made it a tar.xz archive.
> >
> >The first thing I'm doing in this case is to write a mail to upstream
> >a kind mail pointing to Debian's upstream guide[1] and ask for doing
> >proper release traballs.
>
> Done (as you saw). I also asked some other questions I had.
Yes. Your mail was very well done.
> >For the moment (and if upstream might ignore your request) please add a
> >get-orig-source target to debian/rules. You might like to check out
> >
> > Vcs-Git: git://anonscm.debian.org/debian-med/mauve.git
> >
> >as an example where I basically did the same.
>
> Oh, perfect. I will do this next.
OK.
> >That's why we are doing this "inofficial" MoM right now. I'm happy to
> >guide you into this. Robert Blake has not answered the MoM ping. So
> >may be we do it this way officially. Our mail exchanges are exactly
> >what MoM is about: Making sure you will have an easy start and helping
> >you to fight through relevant docs. If Robert Blake will not answer
> >until Wednesday I simply move you into the MoM table and we start
> >tagging our mails with [MoM].
>
> Great. The package I proposed for MoM is a server/hpc cluster
> application. I hope it will be manageable.
I hope we can manage all things - if not in one month you at least can
be guided on the right track to finalise the package. For the first MoM
project we took way longer but finally there was a package.
I added the [MoM] tag to the subject and mentioned the project on the
MoM page.
Looking forward to work together with you
Andreas.
--
http://fam-tille.de
Reply to: