4 ms·
> What if the package you want isn't provided by the distribution? You package it. > What if the distribution's version doesn't support the features you need?
by still_grokking 5y ago
> What if the package you want isn't provided by the distribution?
You package it.
> What if the distribution's version doesn't support the features you need?
You package the version that does.
> What if it can't be built by relying only on things that are already packaged?
You package the dependencies first.
> How do you distribute your software so it runs on other distributions?
Give them the source so they can package it.
> Do you maintain a different build for each package manager?
Yes, that's the whole idea behind distributions.
> What if you want to run on platforms that don't have standard package managers, like MacOS or Windows?
Well, there you anyway downloaded random things form the internet…
But nowadays even those systems have package management that can be used!
> How do you update the packages without internet downloads during provisioning the build?
It's not about disabling package downloads (which come form a trusted source btw).
It's about disabling downloads form random places on the internet.
Also you can use a local package mirror. That's what the build systems of distributions do.
> The C/C++ model has proven to be fatally flawed. It hasn't worked, that's why modern languages eschew reliance on the distributions' package managers, and greenfield C/C++ projects use the same model.
Well, except for all packaged software out there…
> I'd go so far as to say this model is a key reason why we need containerization to deploy modern software today
Nobody needs that. Software form packages just works fine. All the Linux installations around the globe are a prove of that fact.
> since you can't trust software written on distro X runs on distro Y because it packages dependency Z differently all the way up to the root of the dependency tree (glibc, usually).
Of course you can. It works exceptionally fine. After you packaged it.
> The fundamental flaw of this model is that it inverts the dependency tree. Build time dependencies are local to individual projects and need to be handled separately from all other software. With few exceptions, Linux distros make this mistake and it's why we can't rely on distro package management for new projects.
More or less every distro does it wrong? And you know how to do it correctly?
Maybe you should share your knowledge with the clueless people building distributions! Get in touch with for example Debian and tell them they need to stop making this mistake.
By the way: How does your software reach the users when it's not packaged?
At least I hear "sometimes" that users demand proper software packages. But maybe it's just me…
- deleted 5y ago[deleted]
- duped 5y agoI think you're conflating package management for distribution and package management as a build tool. This is the flaw that Linux distributions make. It's why flatpaks and snaps exist. On MacOS and Windows you distribute software as application bundles similar to flatpak/snap. >More or less every distro does it wrong? And you know how to do it correctly? Yes, exactly. For distribution you use snap and flatpak, or application bundles on MacOS and Windows. For building you use a package manager that can install vendored dependencies pinned to specific versions, and do it locally to individual projects so they are not shared across multiple projects. This is the tact taken by modern tools and languages. It's not my idea! It's what everyone building software in the last decade has migrated to. Packaging software so it can be used by any distro's package manager is not viable, and reliance on such an outdated model is why using Linux sucks for everything but writing software to run on a single machine. > At least I hear "sometimes" that users demand proper software packages. But maybe it's just me And when they do you almost never go through the official/trusted mirrors because it will never be up to date, you host your own (maybe put up some signature that no one ever checks) so they just `sudo apt repository add ; sudo apt-get install -y` in your install instructions.
- tentacleuno 5y ago> Packaging software so it can be used by any distro's package manager is not viable, and reliance on such an outdated model is why using Linux sucks for everything but writing software to run on a single machine. Sorry, could you elaborate on why Linux "sucks" for anything but single-user, please? I haven't heard this argument.
- deleted 5y ago[deleted]
- still_grokking 5y ago> It's not my idea! It's what everyone building software in the last decade has migrated to. Well, everybody besides the biggest free software distributors out there, which are Linux distributions… > Packaging software so it can be used by any distro's package manager is not viable, and reliance on such an outdated model is why using Linux sucks for everything but writing software to run on a single machine. Yeh, I get it. That's why we need Docker… Nobody is able to distribute software otherwise. Well, except all those "distributions"… > And when they do you almost never go through the official/trusted mirrors because it will never be up to date, you host your own (maybe put up some signature that no one ever checks) so they just sudo apt repository add ; sudo apt-get install -y in your install instructions. Moment. Does this mean someone managed to build packages that work on different versions of even different distributions, which is obviously impossible as we just learned? This starts getting hilarious! I'm sorry for you that nobody want's to listen to your great ideas. Have you ever considered that you're completely wrong?