Hi Dmitry, On Wed, Oct 21, 2020 at 12:50 AM Dmitry Smirnov <only...@debian.org> 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
