Re: Third-party forks of packaged projects
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
Reply to: