Re: kmer-tools
Hi Afif,
On Sat, May 02, 2015 at 10:53:34PM -0700, Afif Elghraoui wrote:
> >I have checked your last commits and would like to comment on it. You
> >have created several binary packages - withpout checking I'm guessing
> >one per binary in /usr/bin. While this is a possible thing to do I
> >think this is over-engineering and creates a lot of work for you with
> >no practical use.
>
> I was starting to think the same thing as I saw that I would have to
> manage the interdependencies if I kept along this route. My only
> concern was that some of these packages have quite different
> functions. I suspect they are only distributed together because they
> share some dependencies and are written by the same developer.
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.
> 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 we could go with maximum four packages:
> >
> > libkmer<soversion>
> > libkmer-dev
> > kmer-tools (or some similar name)
> > libkmer-doc
> >
> >The text you added as descriptions in debian/control might be useful for
> >some manpages for the tools.
>
> 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? 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.
> >Finally in the Git repository the pristine-tar branch is missing. Did
> >you imported the upstream tarball using
> >
> > git import-orig --pristine-tar ?
>
> 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. Please keep this list in CC if you do so. I
usually start mails like this with
I'm writing you on behalf of the Debian Med team which has the
goal to package all free software which is relevant in the field
of biology for main Debian. Here you can see a list of what we
have done so far:
http://blends.debian.org/med/tasks/bio
This might be more convincing to upstream as if you wrote as "random
person who has a crazy idea".
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. Using pristine-tar is
specifically important exactly in these case to make sure all team
members are using the same tarball. Sp lease commit pristine-tar
for whatever you created using get-orig-source.
> >If yes, please push all branches. If no, please do the latter as
> >described in Debian Med policy.
>
> I will try to do better about following the policy. I have 4-5 sets
> of documentation that I keep flipping back and forth between and I
> sometimes forget to make sure my final work is policy-compliant.
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].
> Thanks for checking my commits :)
You are welcome
Andreas.
[1] https://wiki.debian.org/UpstreamGuide
--
http://fam-tille.de
Reply to: