On Fri, Apr 24, 2020 at 05:28:51PM -0400, Kyle Edwards wrote:
> In that case, the depending
> project "vendors" the third-party dependency with the modifications
> that it needs.
Which is always horrible for us.
If you have any power, please don't do it. Rather find a way to
monkey-patch whatever dependency function you are using or whatever is
possible in your case.
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.
> Obviously, "vendored" dependencies are a no-go in Debian, but how do
> situations like this get resolved?
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'm imagining the modified project
> could be packaged on its own the way any fork would - in that manner,
> it would not be much different from packaging MariaDB even though a
> package for MySQL already exists. Is my intuition correct here?
pacakaging that as a fork it's clearly possible, but it's much more
work, and usually doesn't make sense since that vendorerd patches
libraries likely won't be used by anything else, and would be updated
only together with the "main" software, so separating them is not really
useful.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature