Bug#986320: Stronger advice on when to use native packages

[Sam Hartman <hartmans@debian.org>]

>>>>> "Holger" == Holger Levsen <holger@layer-acht.org> writes:

    Holger> On Mon, May 09, 2022 at 07:16:59PM -0700, Jonathan Nieder wrote:
    >> > Even if that consensus does not exist, there is probably
    >> consensus > that native packages are a poor match for large
    >> packages (because of > the inefficiency of making small updates
    >> to the packaging of native > packages), Do you mean large
    >> packages with a separate upstream existence, or large packages in
    >> general?  I don't think there's such a consensus for large
    >> packages in general: if Debian is the canonical place for a
    >> particular package to be released (e.g., as is true for dpkg),
    >> then it doesn't seem like it would be worth the overhead of
    >> making two releases, one upstream and one for packaging, whenever
    >> updating that package.
 
    Holger> speaking as the debian-edu-artwork maintainer, which at one
    Holger> point in time was a >50mb sized native package: it's pretty
    Holger> annoying to upload 50 or more megabytes for a 2 byte fix of
    Holger> a maintainer script.

I'd much rather upload  a 50M package regularly than deal with the vcs
complexity of separate maintainer and upstream releases in a lot of
cases.
10 years ago sure, that would have been annoying for me, but these days
with modern networks 50M is not a big deal.

Granted not everyone has a fast network.

If there is a consensus that the upstream source split is important for
large packages, it is fairly rough.
I'd definitely like to call that consensus into question and suggest
that it's unclear whether it exists.
It may; my opinion on this issue is definitiely on one side, and that
would make me a poor choice to judge the consensus here.
However, I don't want us to move forward assuming that consensus exists
without actually exploring it.