Hi, Andreas,
On الأحد 3 أيار 2015 00:24, Andreas Tille wrote:
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.
Yes, some of these tools are described in their own scientific
publications. I think this is part of the reason why upstream does not
assign one version number to cover all the components.
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.
I think we could go with maximum four packages:
libkmersoversion
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?
I just thought it was strange to have one library package for several
loosely-coupled/possibly independent libraries.
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.
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.
Done (as you saw). I also asked some other questions I had.
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.
Oh, perfect. I will do this next.
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.
Understood.
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].
Great. The package I proposed for MoM is a server/hpc
