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
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
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
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
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
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
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
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
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
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
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 ap
11 matches
Mail list logo
