Hi Nilesh,
Thanks for the quick answer. Your advice is much appreciated, as always.
Le 13/03/2022 à 15:46, Nilesh Patra a écrit :
On 3/13/22 8:05 PM, Pierre Gruet wrote:
What should I do? My proposal would be to design a multiple upstream
tarball for gatk-bwamem-jni: original one + the sources at the tip of
the Apache2 branch of bwa.> It would build a libbwa.a lib which would
not be installed in /usr/lib, but in a private directory of
gatk-bwamem-jni.
By doing so, I would not interfere with the currently Debian-packaged
bwa and I would also be able to build, run and ship gatk-bwamem-jni...
which would, still, be independent of the bwa that is shipped in Debian.
Does this seem sensible?
Introducing code copies in packages are bad for several reasons - for
instance, possible security issues in the embedded copy that would
go into next stable release; and hence this should be the last resort.
Probably the better thing to do would be to instead talk to upstream
about it and ask them to port the code to latest bwa versions.
If the ETA is sensible, it makes sense to wait; however if nothing else
works, vendoring should work as you proposed.
Sure, security is a big issue and also the reason I asked here.
You're right, anyway upstream should be asked about it first. My
ultimate packaging target is gatk, so I guess we have a bit of work
before getting it: plenty of time to exchange with upstream.
If you want a multi-orig solution, please do it programmatically with
d/watch and d/gbp.conf as for instance done in JS team[1]
[1]: https://wiki.debian.org/Javascript/GroupSourcesTutorial#Manual_way
Incidentally I have already worked on some MUT packages, so yes, I am
used to do so!
Regards,
Nilesh
Best,
--
Pierre
