Hi Dmitry,
On Wed, Oct 21, 2020 at 12:50 AM Dmitry Smirnov wrote:
>
> Yes, at first there will
> be a significant effort but then it will become easier.
I know you put a lot of effort in (as did Michael Stapelberg, with
whom I spent some time before he left), but I don't think our current
approach makes anything easy. It is also why the world is moving in
another direction.
> You are advocating for disruptive
> changes therefore your proposed theoretical solutions have to be available as
> a proof of concept for review.
Did you catch the part about different versions being co-installable?
It would be similar to the freedom we grant to major numbers of shared
object libraries. My point is theoretical only because we do not
presently have it.
> Personally I'm not satisfied with either of those inferior proposals.
How is the second one inferior, please? I think it includes a crucial
missing feature (co-installable versions).
> Look how many packages we already have:
>
>
> https://qa.debian.org/developer.php?login=pkg-go-maintainers%40lists.alioth.debian.org+team%2Bpkg-go%40tracker.debian.org
It's an impressive list; thank you for forwarding it. I am proud to be
on the Golang team. :)
> In the meantime you could follow the established practice that is
> demonstrated to be working on several packaged heavy Golang applications.
Not sure about heavy Golang applications, but our established practice
does work well for the relatively lightweight 'gocryptfs', which I
maintain. That source moves very fast. I often have problems finding
the proper go-fuse or xattr prerequisite required for a new version.
Sometimes they are incompatible with the needs of other packages in
the archive.
As a side note, several "library" packages that gocryptfs relies on
should really be marked "Architecture: any" to exercise their test
suites properly. It is another example of the impedance mismatch in
our current approach. We are confusing sources and libraries, and our
method of shoehorning one into the other ought to be rethought.
> Besides un-vendoring libraries can prevent some CVE issues as well.
Packages could declare vendored sources (or Lintian could scan for
them) for an effective match with their security status.
> If we tolerate full vendoring now, because "there is no better way" yet, then
> there will be no better way for sure.
Please do not despair. I offered full vendoring only in the interest
of compromise, which I believe is a worthwhile goal just like the
consensus we are working on. As a project, we are looking for a better
endpoint together.
Kind regards
Felix Lechner
