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)
