Hello Mo, On Tue 03 Mar 2020 at 04:13AM +00, M. Zhou wrote:
> The fact is that if embedded code copies were prohibited, > I can list a couple of source packages to purge from the archive. > And that would demotivate more contributors. > > The point is that, sometimes disentangling the embedded code > from the upstream source can cost much greater amount of > time and energy from the maintainer. That's somehow harsh > to the contributors. Embedded code copies may have different > and interesting reasons. > > We all like to handle clean and elegant upstreams. But the > fact is that there are always an amount of unelegant upstreams > such as Google (bazel, tensorflow, abseil-cpp), Facebook (pytorch, > folly) which are quite unfriendly to distributions. > > The contributor has only two choices at low cost: 1) totally > ignore this piece of software even if it seemed useful 2) doing > something not quite elegant such as embedding a convenient copy. > > Speaking of policy, "should" is a good trade-off that I agree with. Thank you for your reply. I'm not concerned here with elegance for its own sake. I don't think that is within the remit of ftpteam NEW review! My worry about these embedded code copies is maintainability. We do not have great tools for finding, nor updating, all the embedded copies of a library. So each time we introduce an embedded code copy then we are making it harder to fix bugs in Debian. This is particular important for security fixes. The security team cannot be expected to go around finding multiple copies of libraries and uploading all the packages. AIUI tensorflow is expected to process untrusted input, so we would want it to be easy to fix security problems in its dependencies. Please let me know if I'm misunderstanding the nature of these dependencies. -- Sean Whitton
signature.asc
Description: PGP signature
-- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
