Programming

26326 readers

322 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev

Is it bad form to patch a dependency? (programming.dev)

submitted 1 day ago* (last edited 1 day ago) by staircase@programming.dev to c/programming@programming.dev

14 comments fedilink hide all child comments

My code depends on a library that makes liberal use of patching (replacing text in source code) for its own dependencies. I feel this is bad form, because, for example, that dependency may now conflict irreconcilably with another dependency of mine.

Am I right in thinking patching code is bad form?

you are viewing a single comment's thread
view the rest of the comments

[–] entwine@programming.dev 1 points 19 hours ago (1 children)

Yes and no. It depends on how you manage symbol visibility. There is such a thing as a "private" dependency. For example:

libA uses a patched version of libZ, and breaks ABI compat with the upstream version
Your program links with libA and upstream libZ dynamically

If LibA links with libZ statically, and doesn't expose any internal libZ structures through its own APIs, then there's absolutely no problem. Your code will never directly interact with the internal libZ of libA.

If LibZ is exposed by LibA, or LibA dynamically links with LibZ, then you have a problem. I'm not an expert on dynamic linkers, but they're might be some platform specific workarounds you can do.

Something else I've seen before is some libraries use preprocessor macros for their namespaces. That way, you can change the namespace (and thus symbol names) at compile time. That way, you can have multiple copies of the same library coexisting, even with type safety at compile time.

[–] BB_C@programming.dev 1 points 18 hours ago

Not sure how are you and @kibiz0r@midwest.social coming up with these concerns.

The only correct way to package such software is to vendor dependencies (packaged together or separately). And you can trivially change the sonames of vendored deps in your build scripts so that there are no conflicts whatsoever (I dual-package some stuff against an upstream and a fork and do just that). So dynamic vs. static is not the crux of the issue. The primary concerns are that distributors hate vendoring, irrespective of whether the vendored libs are linked in statically or dynamically. Distributors also hate potentially diverging forks maintained by random downstreams, which is what "patched dependencies" effectively are.

There is always room for some leeway of course, but that would depend on how relevant your software is, and/or whether a maintainer would want to take that burden on.

And finally, sometimes, such dependencies may provide added value that trumps all these concerns. So judging these things is always situational.