On Fri, Sep 03, 2021 at 01:03:35AM +0200, J�r�my Lal wrote:

- should a package debian/control list bundled dependencies to make
sure to avoid duplications ?

Maybe? I noted in my final paragraph that Fedora has a mechanism for
this that we don't, but perhaps Provides is sufficient.

- when a bundled package dependency is already available in debian,
and is the same (unpatched), should the upstream source tarball be
repacked without that dependency, or kept inside the source tarball ?

I omitted this from the policy side, because it seems like this is
already answered in ftp-master practice. Provided the vendored copy is
not used during the build and unless there is a *different* reason for repacking with Files-Excluded, then I see no reason to remove it.
--
emorrp1

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCYTF0qQAKCRDbymUJHySO bInYAP9RbPbaHBwTcIHxk9Djaq6KyprVQ74cQCEC76YvN3pvwgD/Y628tYDm5ZT4 q5LqV8r4UlLjAiEBHk0e3IQ9mViXBgo=
=6Tdk
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Sep 03, 2021 at 02:46:20AM +0200, Jonas Smedegaard wrote:

First of all, thanks for compiling the list of reasonings.

Thanks for taking the time to read through it, I was hoping it would be
a useful observation.

I get the impression that you are framing current state of embedding as
a generally good thing to do, and if I understand that correctly then I disagree with it.

ish? I mostly tried to document current practice rather than have an
opinion on it being good. I do think that the evidence of multiple
independent maintainer teams coming to similar conclusions on the basis
of lack of user benefit and drag on new version velocity indicates the
positive side.

I believe, based on only a day's investigation, that you are in the
minority here. I don't mean that as a bad thing - 1/3 of DDs disagree(d)
with offering non-free alongside main - but I'd like to hear why you
think the maintainers I gave as examples should use their Debian time to unvendor everything?

I suspect that it helps if separating reasons for _encouraging_
embedding (tiny upstream projects and deeply integrated sets of
upstreams, I guess) from reasons for _discouraging_ embdding (all other cases, I guess).

I think the expanded points I gave empower maintainers to make the best decision for their own packages. By laying out the permitted reasons
clearly, it's implied other reasons are not valid, but there's probably something I haven't thought of.

However #907051 also wanted more background on _why_ one might choose
one way or the other, so please do elaborate on this if you can.

Quoting Phil Morrell (2021-09-03 00:38:35)

5. Where only a small number of unrelated projects are bundled, they
SHOULD be uploaded as separate source packages.

Concretely I think not I but ftpmaster objects to the above: Node.js packages embed unrelated packages to meet ftpmaster requirement of a
minimum size source package.

No, I think Node.js is covered by #7 (large number of deps). With #5 I
was attempting to capture the current policy for when _not_ to bundle.
Thanks for the additional background about why the bundling happens.
--
emorrp1

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCYTF6mQAKCRDbymUJHySO bEd5AP0Yd1kDwpjXssOzD2uEQQ2770eOkno87gU6cbC6ILVIpwD/RCfCgoMaiVEs TbAMU+8h0RPsCrXf/JNEhlzQ0E1akwc=
=Hq8I
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Phil Morrell dijo [Fri, Sep 03, 2021 at 02:04:44AM +0100]:

On Fri, Sep 03, 2021 at 01:03:35AM +0200, Jérémy Lal wrote:

- should a package debian/control list bundled dependencies to make
sure to avoid duplications ?

Maybe? I noted in my final paragraph that Fedora has a mechanism for
this that we don't, but perhaps Provides is sufficient.

Although it very seldom the case IMO.

Even if we don't take into account the horrible practice of vendoring
*and then patching* libraries done by some upstreams, we do ship (and
our shipped packages depend on) specific versions of libraries. One of
the ugly things about vendoring is that they bundle _other_ specific
versions of libraries -- and dependencies are often quite hard to
update without wrecking havoc in its whole ecosystem :-(

I omitted this from the policy side, because it seems like this is
already answered in ftp-master practice. Provided the vendored copy is
not used during the build and unless there is a *different* reason for repacking with Files-Excluded, then I see no reason to remove it.

Completely agree. Many packages vendor i.e. rendering libraries to
produce their documentation at build time, and such libraries are not
needed for the package once built.

My example might not be great, because we still like building the
documentation (and thus they would not qualify for Files-Excluded,
only for omitting them from the binary package), but you get the idea
:)

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRgswk9lhCOXLlxQu/i9jtDU/RZiQUCYTI7vwAKCRDi9jtDU/RZ iYAzAQCikdYirEGbGREAZImLk4jhmpPBsH47eh0haPEX9+P5rAD/YEJMpJ+qH7gn /qmzSyZPSyfFrc+4CBIKhy958++3JA0=
=/Eh/
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

2021, സെപ്റ്റംബർ 3 8:22:51 AM IST, Jonas Smedegaard <jonas@jones.dk>ൽ എഴുതി

I am very worried about how complex node-* packages in Debian have
become since ftpmasters explicitly stated a not-too-small rule and we
began more aggressively embedding. E.g. version of each embedded
project is hidden by default, and those packages manually adding virtual >packages has no mechanism to ensure that versions don't jump backwards
or disappear due to a typos.

Apparently reducing package metadata size is more important than every other consideration. It has become very difficult to get new people into js team after we started embedding as the complexity has increased very much from earlier days.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks to Adrian and pabs for their corrections on documenting security support, and there wasn't too much objection to the summary, more to the
sad state of affairs that leads to it and a bit of clarification.

I believe all the major points have cc'd 907051, so would like to
encourage someone more familiar with policy process than I am to draft
an amendment. There should be enough written there now to expand the
section accordingly with more recommendations, and possibly file
wishlist bugs for maintainers to document their reasons in the source.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907051

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCYUIR6AAKCRDbymUJHySO bA3VAQD4btJfuwZjSs7gTi6DQzScdX3Q2EHRjMKPpGobIg704wEA+4NSRP33eoAd rX3lfC5aoE8rf+HKp+SywCnFCmfkKwc=
=PHlB
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)