|
|
Subscribe / Log in / New account

"Critical" projects and volunteer maintainers

"Critical" projects and volunteer maintainers

Posted Jul 20, 2022 9:58 UTC (Wed) by bartoc (guest, #124262)
In reply to: "Critical" projects and volunteer maintainers by rgmoore
Parent article: "Critical" projects and volunteer maintainers

Yeah, there are two "modes" of vendoring I think. If you're using git sub-modules you probably do want to keep up with _some_ upstream, even if it's your own fork. If you want to make changes you might use git-subtree instead. Or derive from "upstream" by simply reading and "rewriting" their code. The last case may not even be considered vendoring, you intend to maintain the thing separately and also want to perhaps change behavior.

To be honest I think all these methods can be fine sometimes, esp the submodule thing is basically a poor-man's package manager and if you share a buildsystem with upstream (or use meson's cmake support thing, I guess) it can be fine.

Hell even the gnulib thing of extracting particular (possible differently licensed) components can work, they do keep things up to date ... most of the time. Ofc a lot of gnulib is much less useful than you would like.

I do kinda wish when people vendored stuff they were better about changing the names of functions, sometimes the vendored library doesn't "escape" across ABI boundaries and can be used with the upstream version just fine, if you change all the symbol names (or dynamically link). Actually have any linkers had support for doing this when static linking, like you can specify that undef symbols should be resolved from different archives for different sets of objects?


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds