Hacker News Reader

Comment by lmm | Hacker News Reader

It's not just a question of being in the official repos. Even if you're running a private repository, the deb tooling is not suitable for building many kinds of software: it's unwilling to play nice with "external" dependencies, and still single-platform and limited in its functionality.

View on HN

> unwilling to play nice with "external" dependencies

But that's a policy decision - the dependencies should themselves be packages, because that's the only way to guarantee reliability.

The inability to install multiple versions is probably the only serious problem with the dpkg model. Even then we might argue that the dependent software should be fixed so that it's not so fussy about specific dependency versions.

Installing multiple versions is possible, given proper semver and good arguments for it: There are quite a few libfoo5, libfoo6, libfoo7 packages. What isn't and shouldn't be possible is installing libfoo 6.6.5 and 6.6.6 at the same time, because those should be compatible. And not being easy to replace (i.e. ABI- and API-compatible) means that security and bug fixes will be missed.

Of course this is work for application as well as library developers, designing and keeping compatibility is hard. Most would rather build the new shiny, consequences be damned.

I think these are noble but naive approaches - we have been developing software for a few decades now and sometimes the software is not compatible without the developer knowing it. You should be able to use whichever version of the software you need.

"Whichever version you need" comes with the responsibility of providing security and bugfix upgrades in a timely fashion. Almost all developers fail spectacularly at this, with latencies in the order of months. This is clearly not viable.

As we are all aware, the most secure software is software that doesn't work at all because of library conflicts.

> sometimes the software is not compatible without the developer knowing it

Sure, but this should be considered either a defect or something highlighted by a major version number jump.

Yeah, but who decides if it's a defect? Maybe the defect is subtle and only manifests in rare cases and the upstream rightfully decides that after a risk/payoff analysis, it's not worth fixing it.

Or maybe he agrees and fixes it and it's included in distributions 7 years later.

I've changed 5 jobs in 7 years (because of life circumstances) and I'm not even a job hopper... How is any commercial shop going to plan around 7 year time frames?

Well, within a debian distribution the Debian developer responsible for the downstream package would get the dependency fixed, either themselves or by badgering the maintainer, and use the fixed Debian version. This gives Debian a consistent set of packages that work together. Yes, it's a lot of work and it's why Debian are behind other distributions and don't include Hadoop. But it reduces the unpleasant surprises.

It's effectively part of insisting that it's properly Free software - if you can't maintain your own bugfixed fork, but have to keep going to an external organisation for their version, is it really Free?

This was my experience as a developer on a SOA team that provided APIs for the rest of the organization (a large regional healthcare system). Even changes that didn't officially break the API could break our customers in ways we didn't anticipate.

When I left that position, we were in the middle of an OpenShift (k8s) deployment, and one of the things motivating the change was the ability to more easily run separate versions of services for different customers if the need arose. Yes, this would put a lot more burden on us as the service provider, but it would also allow us to iterate faster while maintaining stability.

> The inability to install multiple versions is probably the only serious problem with the dpkg model.

Also can't install to separate disks.

That's unlikely. Worst case: examine where the package will put its files, and prep your system with symbolic links to directories residing on a file system on the other disk(s).

But that raises the question: why are your file systems sensitive to disk drives? Use a layer (or more) of indirection through LVM and RAID so to make the drive placement opaque and robust.

> why are your file systems sensitive to disk drives?

A couple of systems I have at home have a 16GB primary disk, so it is useful to be able to put things on an external disk. I have yet to see any package manager that can actually handle that.

> Use a layer (or more) of indirection through LVM and RAID...

Yeah, that's a great idea, just introduce more complication and abstraction to make up for a shortcoming in how Linux developers think about applications.

Or, just have your programs be self contained in a single file or folder and put them wherever it makes sense.

> it's unwilling to play nice with "external" dependencies

This baseless assertion is simply out right wrong. See for example Debian's docs on Private Package Archive:

https://wiki.debian.org/DebianRepository/Setup

Hear hear. If anything .debs dont care enough where dependencies come from. As long as the package name matches you are good. I have no complaints about debian packaging. I've used lots of different ones. All official packages are signed and its easy to sign your own packages.

Maven, on the other hand, is plain scary.

Reply on news.ycombinator.com