> I think almost all of these qualify as "Core system libraries that > pretty much everything depends on.". > Building their C dependencies from vendored copies (if that is even > supported) and statically linking them seems like a pretty bad idea in > almost all cases here, especially for things where the version of a > program on the "host" and the accompanying shared library should > match. Yes, we're in complete agreement. I'm not suggesting anything like that. Vendoring libraries like openssl is a bad idea. What I'm saying is that it's not very logically justified to say that just because core system libraries like openssl shouldn't be vendored, all vendoring is disallowed regardless of how small and focused they are or how few dependents they have. Because - most C libraries have "dark dependencies" that are effectively the same but worse, in some ways. Given the choice between 100 Rust packages vendoring 10 different copies of the sha256 crate and 100 C packages with 100 separate copies of sha256.c sitting in their source trees (which seems like an entirely realistic comparison), why would the latter be completely A-OK while the latter is completely disallowed? > But ... none of these "tiny" Rust crates are dynamically linked in > Fedora anyway - because Rust doesn't really support that? > So I fail to see your point there, unless you meant to say "C projects > don't 'bundle', they just often 'copy' some code into their > projects"? > > Fabio Yes, that's essentially what I'm saying. I feel like the "no bundling" policy draws distinctions that don't entirely make sense, especially when it comes to the small, focused leaf-node dependencies that people often complain about. Clearly the "left-pad" scenario is bad and should be avoided, but on the other hand is having 800 different linked list implementations, 500 different hash table implementations, 25 different half-baked XML parsers, really so much "better", or is it just what we're used to? _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
