Re: Third-party forks of packaged projects
On 4/24/20 11:28 PM, Kyle Edwards wrote:
> Hello,
>
> I have a question about how Debian handles modifications to third-party
> dependencies. Sometimes a project relies on another project, but has
> made modifications to that project that never went into upstream,
> either because upstream has abandoned the project or because the
> changes are not appropriate for upstream. In that case, the depending
> project "vendors" the third-party dependency with the modifications
> that it needs.
>
> Obviously, "vendored" dependencies are a no-go in Debian, but how do
> situations like this get resolved? 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?
>
> Kyle
I'd say that it depends, and that it should be addressed on the
case-by-case basis.
If the library you need to package isn't needed by any other package,
simply apply the needed patch and upload. Even better if it's only a
build-dependency, in which case it wont ever be a problem.
I did this for python3-antlr3 which was needed at build time only by
Congress, and which I don't think any other package will ever need in
Debian. If some day, a package will need python3-antlr3, then probably
we can make 2 different binaries conflicting each other. Python3-antlr3
is only a build dependency, so it's really not a problem if we need to
add such conflicts: statement.
But we could generalize this even for libraries needed at runtime,
analyzing if there's a big chance or not that 2 programs will need
different flavor of the same library.
The other possibility (which is probably the best way forward) is to
convince your upstream that he did a fork, and that it should be renamed
to avoid conflicts.
Cheers,
Thomas Goirand (zigo)
Reply to: