MIME-Version: 1.0
References: 
 <CAMp+ueYqZNwA5SnZV3-iPOyrmQwnwabyMNMOsu-Rq0sLAa2b0g@mail.gmail.com>
 <Z9GPdbIu89nMuB60@msg.df7cb.de>
 <CAMp+ueYwj54J4au4+MBtgR45KWAf+JLB6PX8-QWe7md2dDwgjw@mail.gmail.com>
 <CAOMoQbREwfeDARhD-Hxvfoh=oLNQWKbhxU4qdUcL80xfOQbhTQ@mail.gmail.com>
In-Reply-To: 
 <CAOMoQbREwfeDARhD-Hxvfoh=oLNQWKbhxU4qdUcL80xfOQbhTQ@mail.gmail.com>
From: Smolkin Grigory <smallkeen@gmail.com>
Date: Sun, 16 Mar 2025 14:32:39 +0700
Message-ID: 
 <CAMp+ueYLbjjVuvUJPsi7zQSW0bM++xAcg=SR7RSSzNDmgLOqhw@mail.gmail.com>
Subject: Re: Packages for pg_doorman
To: Bradford Boyle <bradford.d.boyle@gmail.com>
Cc: Christoph Berg <myon@debian.org>, pgsql-pkg-debian@postgresql.org
Content-Type: multipart/alternative; boundary="000000000000d1e832063070ad8b"
Archived-At: 
 <https://www.postgresql.org/message-id/CAMp%2BueYLbjjVuvUJPsi7zQSW0bM%2B%2BxAcg%3DSR7RSSzNDmgLOqhw%40mail.gmail.com>
Precedence: bulk

--000000000000d1e832063070ad8b
Content-Type: text/plain; charset="UTF-8"

> Can we use cargo vendor?
> https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
>My understanding is that Debian policy >does not permit downloading
>during the build [0].

>Would it be acceptable to install the compiler from https://rustup.rs/
during package building?
>> My understanding is that Debian policy does not permit downloading
during the build [0].

Ok, I suppose we have to live with distribution compiler. Though, it may
make some old systems without rust 1.70.0 unsupportable.

>> According to this post [1] on the debian-rust mailing list, "vendoring
should be avoided unless there is a very good reason not to".
>> The Debian Rust packaging team has a pretty comprehensive guide [2] and
it looks like they have tooling to help assist with the packaging process.

I think we have a very good reason here - a lot of distributions of
different versions with different libversions. Even making it just to be
"compilable" would require tremendous effort, supporting it will be
unmanageable.

I see no good reason not to use vendoring in case of "multiple
distribution"-build process.
    1. It's a tarboll artifact, released with main project, under the same
release tag.
    2. It is reproducible and has public hash, so it can be verified.
    3. It allows local build, nothing has to be downloaded.
    4. Consistent binary behavior across multiple distributions.

--000000000000d1e832063070ad8b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container" dir=3D"a=
uto"><div dir=3D"ltr" class=3D"gmail_attr"><div dir=3D"ltr" class=3D"gmail_=
attr">&gt; Can we use cargo vendor?</div><div dir=3D"ltr" class=3D"gmail_at=
tr">&gt; <a href=3D"https://doc.rust-lang.org/cargo/commands/cargo-vendor.h=
tml">https://doc.rust-lang.org/cargo/commands/cargo-vendor.html</a></div><d=
iv dir=3D"ltr" class=3D"gmail_attr">&gt;My understanding is that Debian pol=
icy &gt;does not permit downloading</div><div dir=3D"ltr" class=3D"gmail_at=
tr">&gt;during the build [0].</div><div dir=3D"ltr" class=3D"gmail_attr"><b=
r></div><div dir=3D"ltr" class=3D"gmail_attr">&gt;Would it be acceptable to=
 install the compiler from <a href=3D"https://rustup.rs/">https://rustup.rs=
/</a> during package building?</div><div dir=3D"ltr" class=3D"gmail_attr">&=
gt;&gt; My understanding is that Debian policy does not permit downloading<=
/div><div dir=3D"ltr" class=3D"gmail_attr">during the build [0].</div><div =
dir=3D"ltr" class=3D"gmail_attr"><br></div><div dir=3D"ltr" class=3D"gmail_=
attr">Ok, I suppose we have to live with distribution compiler. Though, it =
may make some old systems without rust 1.70.0 unsupportable.</div><div dir=
=3D"ltr" class=3D"gmail_attr"><br></div><div dir=3D"ltr" class=3D"gmail_att=
r">&gt;&gt; According to this post [1] on the debian-rust mailing list, &qu=
ot;vendoring should be avoided unless there is a very good reason not to&qu=
ot;.</div><div dir=3D"ltr" class=3D"gmail_attr">&gt;&gt; The Debian Rust pa=
ckaging team has a pretty comprehensive guide [2] and it looks like they ha=
ve tooling to help assist with the packaging process.</div><div dir=3D"ltr"=
 class=3D"gmail_attr"><br></div><div dir=3D"ltr" class=3D"gmail_attr">I thi=
nk we have a very good reason here - a lot of distributions of different ve=
rsions with different libversions. Even making it just to be &quot;compilab=
le&quot; would require tremendous effort, supporting it will be unmanageabl=
e.=C2=A0</div><div dir=3D"ltr" class=3D"gmail_attr"><br></div><div dir=3D"l=
tr" class=3D"gmail_attr">I see no good reason not to use vendoring in case =
of &quot;multiple distribution&quot;-build process.</div><div dir=3D"ltr" c=
lass=3D"gmail_attr">=C2=A0 =C2=A0 1. It&#39;s a tarboll artifact, released =
with main project, under the same release tag.</div><div dir=3D"ltr" class=
=3D"gmail_attr">=C2=A0 =C2=A0 2. It is reproducible and has public hash, so=
 it can be verified.</div><div dir=3D"ltr" class=3D"gmail_attr">=C2=A0 =C2=
=A0 3. It allows local build, nothing has to be downloaded.</div><div dir=
=3D"ltr" class=3D"gmail_attr">=C2=A0 =C2=A0 4. Consistent binary behavior a=
cross multiple distributions.</div></div></div></div>

--000000000000d1e832063070ad8b--