How do you not bundle in dependencies when coding in, say, Java ? The Java packages on Debian are for the most part outdated. It's way more practical to just use Maven, build a fat jar and be done with it.
It depends who your end users are. If the people responsible for running the code do it as their full time job, then yes, bundling the dependencies is more practical because you have a team of full-time engineers to handle security updates, rollbacks, etc. But if you're pushing it out to people who expect to just be able to fire and forget, not relying on your distro to manage dependencies for you is going to result in a world of hurt.
To not bundle dependencies, use the Java packages in Debian stable and if you find one with a missing feature or unfixed bug, then backport that from Debian unstable or from upstream.
Debs and Rpms are fine for configuring the machine, as soon as you have it where machines and application services aren't a 1:1 relationship that will lead you in the direction of dependency hell. As each application will want slightly different versions you'd have to be very careful which version you installed.
You can cheat a little. For example I am using some system debs for python packages, but if there were more than a handful of python utility packages that can get unmanageable fast. That leads naturally to the fat jar/virtualenv/static binary approach with manually managed dependencies which gives you isolation between applications, and all the associated costs.
It's very common to have breaking changes that you need to carefully manage in a company's internal code, and where managing that as a full-on deprecation isn't worth the effort. Moving faster is often the better choice compared to never refactoring and improving the codebase.
I'm talking about internal libraries of a company, where there is no proven library with a stable interface as it's continuously evolving - similar to a young library in the OSS world that has no reasonable substitute. It might be something like a new parameter to a function, or an additional method call you need to make in a given version.
Applications that are written specifically in order to be run on the servers of a given company instead of being written to be general purpose have vastly different tradeoffs involved when it comes to choosing dependencies.
And when the library is not packaged in the repo, should I then build the package myself ?
If we were in an ideal world we would do that, but unfortunately we're not, and in my experience it's way easier for the dev AND for the sysadmin to use Maven and build a fat jar.
How do you not bundle dependencies programming in anything? If you want to be portable across Linuxes, you can't even count on tcsh or env being installed at the same path. Counting on the stuff installed with the system unleashes a world of pain on the user.
>you can't even count on tcsh or env being installed at the same path
This is what tools like Autoconf and pkg-config take care of. Lots of people use them to discover executables and libraries and generate files with the right machine-specific variables in them. You should never assume that binaries are in /usr/bin or that libraries are in /usr/lib. A lot of packaging issues are caused by such assumptions.
If you use the right tools, you don't have to bundle your dependencies. Bundling introduces a serious maintenance burden onto the developers and the packagers. It's easy to avoid bundling for C libraries and things, but with the prevalence of language-specific package managers, it's become a harder problem because everyone just assumes that you will fetch dependencies through it and never use the system package manager. It's a sad state.
Yes, but many of us have no intention of being portable across Linuxes. Our software is designed to be deployed to machines we control. If users want to deploy it to some other distro, they're free to package it themselves.
