On Sun, Jun 21, 2020 at 09:15:52AM +0200, Andreas Tille wrote:
> 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?
Yes that's my suggestion.
If symlink doesn't work, may be a 'cp' does.
> 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.
I agree get-origin-source may work and probably save even more efforts.
> 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.
Backport changes to what packaged lib? Sorry
> > 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.
BTW: I'm unable to build the gindex tests, probably missing sources.
Even across all upstream git(s) history :-/
Regards,
--
Antoni Villalonga
https://friki.cat/
