Re: graphmap2, gindex, seqlib & some more friends
Hi Antoni,
On Sun, Jun 21, 2020 at 07:36:42AM +0000, Antoni Villalonga wrote:
> > 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.
OK.
> If symlink doesn't work, may be a 'cp' does.
That's an implementation detail but as I said there might be other
solutions.
> > 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.
OK.
> > > * 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
See commit
https://salsa.debian.org/med-team/bamtools/-/commit/130504f9b81c0bfe865a9da2a3feb30e62052463
in bamtools where I added a feature that was added in the code copy
shipped with tiddit. I really do not like this approach but given that
the opal code copy inside seqlib might add a similarly simple,
non-invasive feature that might be an option.
> > > 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 :-/
I've checked your approach to gindex where you add seqlib as a patch. I
do not think this is a good idea. We should first sort out seqlib
packaging. I also think we should drio src/sparsehash in favour of a
Build-Depends: libsparsehash-dev and usually removing lib/googletest in
favour of the Debian packaged googletest.
My gut feeling about isovic-seqlib is the following:
1. Wait a week whether we get a sensible name decision.
If no suggestion is given be upstream I think your choice
isovic-seqlib
might work
2. Sort out code-copied lib one after the other whether it can
be replaced by the Debian packaged version and do so.
3. See whether gindex builds with the isovic-seqlib we create
that way.
I'd personally start with item 1. (=wait) and pick other of the
existing targets meanwhile.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: