Re: Third-party forks of packaged projects

2020-04-29 Thread Kyle Edwards
On Wed, 2020-04-29 at 10:21 +0100, Alastair McKinstry wrote: > I think vendoring libraries that are only used by this package is > fine. > > I would however put them in a "public" place and namespace (eg > /usr/lib/$ARCH/libatl.* ) rather than a subdir or namespace > ('libatl-adios')  so that ther

Re: Third-party forks of packaged projects

2020-04-29 Thread Alastair McKinstry
On 28/04/2020 21:44, Kyle Edwards wrote: > On Sat, 2020-04-25 at 20:31 +0200, Thomas Goirand wrote: >> I'd say that it depends, and that it should be addressed on the >> case-by-case basis. > I do have another scenario I'd like to address. ADIOS uses a stack of > closely related but separate proj

Re: Third-party forks of packaged projects

2020-04-28 Thread Kyle Edwards
On Sat, 2020-04-25 at 20:31 +0200, Thomas Goirand wrote: > I'd say that it depends, and that it should be addressed on the > case-by-case basis. I do have another scenario I'd like to address. ADIOS uses a stack of closely related but separate projects, all developed by Greg Eisenhauer, which, as

Re: Third-party forks of packaged projects

2020-04-27 Thread Thomas Goirand
On 4/27/20 10:34 PM, Kyle Edwards wrote: > On Sat, 2020-04-25 at 20:31 +0200, Thomas Goirand wrote: >> 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 p

Re: Third-party forks of packaged projects

2020-04-27 Thread Kyle Edwards
On Sat, 2020-04-25 at 20:31 +0200, Thomas Goirand wrote: > 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. This brings up an interesting questio

Re: Third-party forks of packaged projects

2020-04-25 Thread Thomas Goirand
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 ab

Re: Third-party forks of packaged projects

2020-04-24 Thread Paul Wise
On Fri, Apr 24, 2020 at 10:16 PM Kyle Edwards wrote: > I did not realize that exceptions were occasionally made for vendored > libraries There is no exception for vendored libraries, but occasionally people just upload without doing the work needed to find them or deliberately ignoring the rules

Re: Third-party forks of packaged projects

2020-04-24 Thread Paul Wise
On Fri, Apr 24, 2020 at 9:29 PM Kyle Edwards wrote: > 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 aba

Re: Third-party forks of packaged projects

2020-04-24 Thread Kyle Edwards
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

Re: Third-party forks of packaged projects

2020-04-24 Thread Mattia Rizzolo
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