On Sat, 2020-04-25 at 00:02 +0200, Mattia Rizzolo wrote: > If the upstream maintainer of that library is not available anymore > and > the project is clearly dormient, perhaps you can take over > officially? > Or if that patch is "acceptable" just leave it on the bug tracker, > and > within debian that patch could be applied, so that at least downstram > we > can strip off that vendored library. That's cleraly possible only if > that patch doesn't break stuff, etc.
Mattia, Thanks for the insight. Two years ago I encountered this issue with VTK. We use a modified version of libharu, and submitted our patches upstream, but upstream has not been active in 5 years. I attempted to submit our patches to Debian, but was told it would be better if we forked it outright and made our own release. In the end, I decided it wasn't worth the effort. I am now encountering a similar issue with ADIOS2 (https://github.com/o rnladios/ADIOS2). We use a modified version of enet (https://github.com /GTkorvo/enet), and from what I understand, we can't use the upstream version, so this is a situation where either enet would have to be vendored with ADIOS or we would have to package our fork. > vendored dependencies are not really a strict no-go. cases like what > you describe are one reason to keep them vendored within a package, > and > the security team tries keep a list of such vendored libraries, but > since few maintainers reports back changes in this area, that list is > not really that good (reason not to vendor libraries!!). I did not realize that exceptions were occasionally made for vendored libraries - I thought the policy was "if the dependency can't be externalized, then it can't be used"... though I do recall a recent discussion about Docker/k8s having this issue. Kyle
