>>>>> "Dmitry" == Dmitry E Oboukhov <[email protected]> writes:
Dmitry> On the other hand: if I package the aforementioned Bottles
Dmitry> and a reviewer rejects it with something like “the following
Dmitry> packages already exist in Debian, please rework the package”
Dmitry> and lists e.g. python3-gi, python3-gi-cairo, python3-cairo,
Dmitry> python3-yaml, python3-pycurl, python3-requests,
Dmitry> python3-markdown, python3-chardet, python3-idna,
Dmitry> python3-urllib3, python3-certifi, python3-pefile,
Dmitry> python3-yara, python3-charset-normalizer, python3-orjson,
Dmitry> python3-pathvalidate, python3-icoextract, patool, fvs
Dmitry> — who is “right” in that situation?
Dmitry> The wording of Policy leaves that unclear.
I think that preferring not to vendor is valuable for reasons that
others have stated.
However, I would support making it clear that the maintainer is the
authority on this trade off, and that disagreeing with the maintainer is
not a reason to reject a package from the archive.
I think it should still be something that can be brought to the TC.
I.E. I would support finding a mechanism to allow such a reviewer to
file a bug, but not to reject from new. And I would support a maintainer
tagging such a bug as wontfix, but would also support someone bringing
the issue to the TC if they thought they could get enough of a super
majority to override a maintainer.
I.E. in cases where the vendoring was really breaking security.
