Bug#986320: Stronger advice on when to use native packages
On Tue, May 10, 2022 at 08:32:32AM -0600, Sam Hartman wrote:
> >>>>> "Holger" == Holger Levsen <holger@layer-acht.org> writes:
> 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.
There cannot be any consensus because "native pakages" cover widely
different packages and situation, and anyone has in mind their own
situation, and there are no general rules.
I expect most developers do not maintain any "native pakages",
and for a minority, this is the opposite, almost all their
packages are native.
For me it is a mixed bag, with packages that "obviously" should be
native, other that should not and some other it could go both way.
tl;dr: natives packages are too diverse to be covered by a single rule.
Sometime we should trust maintainer good judgement since they are the
one that are the most impacted.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: