Re: ipp-usb 0.9.27 announce

Hi Zdenek & Johannes,

I probably need to explain some details.

First of all, when working with external dependencies, Go binds to 
specific versions of external libraries. This is done not by version 
number—which can easily be changed, either intentionally or by 
mistake—but by the cryptographic hash of the entire source code of the 
external libraries. Thus, the library sources actually used for building 
are always consistent with a particular version of the library.

Second, no changes in the goipp master will affect the building of 
ipp-usb. If I want to upgrade to the next goipp version, this is always 
an explicit action on the ipp-usb side (not on the goipp side).

The relationship between a project that uses certain libraries (i.e., 
ipp-usb) and projects that provide these libraries is controlled by the 
go.mod and go.sum files, which are part of the versioned source of 
ipp-usb. Therefore, any changes in dependencies will be visible in the 
ipp-usb repository.

In the Go ecosystem, this is referred to as a "reproducible build." By 
the way, the Go toolchain itself contains many external libraries in 
vendored form.

Additionally, vendored libraries are only used for building packages 
that vendor them and are never installed locally. Consider it not as an 
independent copy of the library, but as a kind of cache. The consistency 
of this cache with the master copy is strictly enforced by the Go toolchain.

Thus, vendoring goipp does not violate your KSSSS principle and actually 
simplifies logistics, as any good cache does.

The -mod=vendor option is only required by the older Go compiler, which 
is still used on Debian 10. To my surprise, there is still some demand 
for ipp-usb to run on this old OS, so I will support it for a reasonable 
time. Newer versions of the Go toolchain handle this automatically.

You may delete the vendor directory in your RedHat build or leave it; it 
will not change the result. However, you cannot modify source files in 
the vendored copy and expect your changes to be included in the ipp-usb 
build; Go will not allow that.

So essentially, nothing has changed from your perspective. You can 
continue to distribute the goipp package with RedHat and CentOS; it is 
now just another Go library package that does not affect ipp-usb. You 
may remove the build dependency from the ipp-usb .spec file, but you are 
not required to do so.

Regarding SUSE, distributing goipp as a separate vendor.tar.zst may work 
for SUSE, but it compromises source code transparency. SUSE users cannot 
easily verify that ipp-usb for their system is built exactly from the 
sources published on GitHub. I believe that source code transparency is 
a significant feature of open-source projects from a cybersecurity 
standpoint; it helps ensure that our users will not inadvertently 
receive malicious code from official sources.

Honestly, I have also used this practice in OpenSUSE build services 
because it is simpler than building an "intermediate" package. However, 
it is no longer necessary.

I hope my explanation clarifies things for now. Please feel free to ask 
additional questions if any details are still unclear.

--
Best regards, Alex.