Re: graphmap2, gindex, seqlib & some more friends
Hi Antoni,
On Sun, Jun 21, 2020 at 06:29:26AM +0000, Antoni Villalonga wrote:
> Hi,
>
> I've been looking at that "ecosystem" as you already have done.
> I think the main purpose of med-team is to get a working "graphmap2" binary
> package.
That's correct.
> Upstream compilation script is static between all "isovic" pieces.
> What if we also glue all together in a similar way?
>
> I mean, provide various -source packages ("gindex-source",
> "isovic-seqlib-source", etc) and graphmap2 Build-Depends on them. Create
> corresponding symlinks on d/rules getting the required hierarchy and build the
> glued binary "./bin/graphmap2".
I'm not sure whether I understand you correctly. So your suggestion is
not to build the actual sources but rather ship the sources in an
Architecture: all package (as if packaging kind of header only library)
and simply build these together with graphmap2 after copying these into
graphmap2 source tree (I guess symlink will not work since we can not
write to some place in /usr where the sources would reside than). Did
I understood this correctly?
If so I have some not so good gut feeling about it. While I agree that
this might lead to some working graphmap2 its deriving much from the
Debian packaging philosophy.
If its too much of a burden to build those single libraries and we need
everything in one source tree I'd rather draft some get-orig-source for
graphmap2 and assemble everything in one source package. In the end the
technical effect would be the same but we do not need to bother
ftpmaster several times to carry several source projects as binary
packages.
However, my old fashioned Debian mind keeps on thinking that modularised
packaging of separate libraries is the better way to go.
> Note isovic-seqlib have some more internal sources in ./src/libs/:
> * edlib (compatible with med-team version?)
> * libdivsufsort (compatible?)
> * seqan (compatible?)
I've seen this. Seqlib is really a hard one. Starting with the name
space pollution[1]
> * opal (extended from original source. Upstream widely forked)
Uhmmm. May be we should open another issue to merge back those changes
to opal upstream? Sometimes we could even backport changes to the
Debian packaged lib. I did this once with a non-invasive change, but
for sure that's questionable.
> It's a real Matryoshka nightmare :-p
I agree that seqlib is really a stumbling stone.
> Make sense? Is a dirty way we should avoid for some reason? I think "isovic"
> projects are quite abandoned/static by now.
I wonder what other readers of the list might think.
> May be we can start with two packages: "gindex-source" and
> "isovic-seqlib-source" (including ed, divsufsort, seqan, opal).
> And when required create "edlib-source", "seqan-source", etc. It may require
> extra efforts and patch the code to adapt to upstream changes.
I have not checked gindex jet but I'd love to understand seqlib first
and wait for an answer from upstream.
> PS: Feel free to reply to the med-team list if you prefere open discussion
Ahh, yes, sure. I always insist on open discussion. ;-)
Thanks a lot for your investigation
Andreas.
[1] https://github.com/isovic/seqlib/issues/2
--
http://fam-tille.de
Reply to: