Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C-Shaped Hole in Package Management

nesbitt.io

Post reply on HN
Print view View original

51–60 of 77 posts

Re: The C-Shaped Hole in Package Management

#51

Post by geraldcombs »

rwmj wrote: post #2

Please don't. C packaging in distros is working fine and doesn't need to turn into crap like the other language-specific package managers. If you don't know how to use pkgconf then that's your problem.

What "distro" package manager is available on Windows and macOS? vcpkg doesn't provide binary packages and has quite a few autotools-shaped holes. Homebrew is great as long as you're building for your local machine's macOS version and architecture, but if you want to support an actual user community you're SOL.

Re: The C-Shaped Hole in Package Management

#52

Post by advael »

I think system package managers do just fine at wrangling static library dependencies for compiled languages, and if you're building something that somehow falls through the cracks of them then I think you should probably just be using git or some kinda vcs for whatever you're doing, not a package manager

But on the other hand, I am used to arch, which both does package-management ala carte as a rolling release distro and has a pretty extensively-used secondary open community ecosystem for non-distro-maintained packages, so maybe this isn't as true in the "stop the world" model the author talks about

Re: The C-Shaped Hole in Package Management

#53

Post by pornel »

Has anyone here even read the article?! All the comments here assume they're building a package manager for C!

They're writing a tool to discover and index all indirect dependencies across languages, including C libraries that were smuggled inside other packages and weren't properly declared as a dependency anywhere.

"Please don't" what? Please don't discover the duplicate and potentially vulnerable C libraries that are out of sight of the system package manager?

Re: The C-Shaped Hole in Package Management

#54

Post by duped »

amiga386 wrote: post #49
duped wrote: post #39

Earlier quoted context omitted.

Linking against every distro-supplied glibc to distribute your own software is as unrealistic as getting distributions to distribute your software for you. The model is backwards from what users and developers expect. But that's not the point I'm making. I'm attacking the idea that they're "working just fine" when the above is a bug that nearly everyone hits in the wild as a user and a developer shipping software on…

It's hardly unrealistic - most free software has been packaged, by each distro. Very handy for the developer: just email the distro maintainers (or post on your mailing list) that the new version is out, they'll get round to packaging it. Very handy for the user, they just "apt install foo" and ta-da, Foo is installed. That was very much the point of using a Linux distro (the clue is in the name!) Trying to work in a…

User now waits for 3rd party "maintainers" to get around to manipulating the software they just want to use from the 1st party developer they have a relationship with. If ever.

I understand this is how distros work. What I'm saying is that the distros are wrong, this is a bad design. It leads to actual bugs and crashes for users. There have been significant security mistakes made by distro maintainers. Distros strip bug fixes and package old versions. It's a mess.

And honestly, a lot of software is not free and won't be packaged by distros. Most software I use on my own machines is not packaged by my distro. ALL the software I use professionally is vendored independently of any distribution. And when I've shipped to various distributions in the past, I go to great lengths to never link anything if possible that could be from the distro, because my users do not know how to fix it.

Re: The C-Shaped Hole in Package Management

#55

Post by [deleted] »

sebastos wrote: post #44
JohnFen wrote: post #6

Earlier quoted context omitted.

I agree entirely. C doesn't need this. That I don't have to deal with such a thing has become a new and surprising advantage of the language for me.

I find this sentiment bewildering. Can you help me understand your perspective? Is this specifically C or C++? How do you manage a C/C++ project across a team without a package manager? What is your methodology for incorporating third party libraries? I have spent the better half of 10 years navigating around C++'s deplorable dependency management story with a slurry of Docker and apt, which had better not be part of…

[deleted]

Re: The C-Shaped Hole in Package Management

#56

Post by Piraty »

josefx wrote: post #9

> Conan and vcpkg exist now and are actively maintained I am not sure if it is just me, but I seem to constantly run into broken vcpkg packages with bad security patches that keep them from compiling, cmake scripts that can't find the binaries, missing headers and other fun issues.

yes, i found conan appears to have lax rules regarding package maintenance which leads to incosistent recipes

Re: The C-Shaped Hole in Package Management

#57

Post by spauldo »

sebastos wrote: post #44
JohnFen wrote: post #6

Earlier quoted context omitted.

I agree entirely. C doesn't need this. That I don't have to deal with such a thing has become a new and surprising advantage of the language for me.

I find this sentiment bewildering. Can you help me understand your perspective? Is this specifically C or C++? How do you manage a C/C++ project across a team without a package manager? What is your methodology for incorporating third party libraries? I have spent the better half of 10 years navigating around C++'s deplorable dependency management story with a slurry of Docker and apt, which had better not be part of…

You're confusing two different things.

For most C and C++ software, you use the system packaging which uses libraries that (usually) have stable ABIs. If your program uses one of those problematic libraries, you might need to recompile your program when you update the library, but most of the time there's no problem.

For your company's custom mission critical application where you need total control of the dependencies, then yes you need to manage it yourself.

Re: The C-Shaped Hole in Package Management

#58

Post by sebastos »

spauldo wrote: post #57
sebastos wrote: post #44

Earlier quoted context omitted.

I find this sentiment bewildering. Can you help me understand your perspective? Is this specifically C or C++? How do you manage a C/C++ project across a team without a package manager? What is your methodology for incorporating third party libraries? I have spent the better half of 10 years navigating around C++'s deplorable dependency management story with a slurry of Docker and apt, which had better not be part of…

You're confusing two different things. For most C and C++ software, you use the system packaging which uses libraries that (usually) have stable ABIs. If your program uses one of those problematic libraries, you might need to recompile your program when you update the library, but most of the time there's no problem. For your company's custom mission critical application where you need total control of the dependenci…

Ok - it sounds like you’re right, but I think despite your clarification I remain confused. Isn’t the linked post all about how those two things always have a mingling at the boundary? Like, suppose I want to develop and distribute a c++ user-space application in a cross platform way. I want to manage all my dependencies at the language level, and then there’s some collection of system libraries that I may or may not decide to rely on. How do I manage and communicate that surface area in a cross platform and scalable way? And what does this feel like for a developer - do you just run tests for every supported platform in a separate docker container?

Re: The C-Shaped Hole in Package Management

#60

Post by arkt8 »

The biggest difficult is not that, is the many assumptions you need when writing a makefile and how to use different versions of same library. The LD_PATH is something had as potentially risky. Not that it be... but assumptions of the past, like big monsters, are a barrier to the simpler C tooling.
Post reply on HN