Packaging and dependencies

[Ben Finney]

Steve Holden <steve at holdenweb.com> writes:

> Ben Finney wrote:
> > So, if fifteen different programs depend on library X, we'd have
> > fifteen *separate* installations of library X on the same machine?
> >
> You need to get your opinions up to date. Fifteen copies of a single
> library is nothing in terms of the code bloat that has happened over
> the last forty years, and most of that bloat is for programmer
> convenience, either in package development or distribution.

Thanks for the straw man, but I'll decline.

The issue with multiple copies of the same library is *not* disk
storage bloat, but violation of DRY: Don't Repeat Yourself. When the
above putative library X is found to have a bug and needs to be
upgraded to fix, it's wasteful of resources to have to track down
*every* instance of that library, in all the places where separate
packages expect to find it — and it's a recipe for omitting one or
several of those multiple instances, thus getting hard-to-track errors
in code that *should* exist in one place on the system.

> While it's all very well to say that there should only ever be one
> true version of a library this requires that developers constrain
> themselves (sometimes in ways they consider unreasonable) to
> backwards compatibility for the entire lifetime of their code.

Not at all. If the package management system is designed well — like
in most modern operating systems — new versions can be installed, and
even relied upon by multiple packages, while the old one stays on the
system for those packages that still haven't migrated to the new. The
foolish part is to have multiple copies of the *same* code scattered
around the system, with different packages looking for the same code
in different places.

> > And when it comes time to upgrade library X because a security
> > flaw is discovered, each of the fifteen instances must be upgraded
> > separately?
> >
> Yes. Better than upgrading a single library shared between fifteen
> applications and having two of them break.

Then allow the old library to stay on the system, in *one* single,
known location, for the applications that need it; and the new library
in *its* single known location for the applications that use it.

> Agreed, but until we reach the ideal situation where everybody is
> using the same package dependency system what's your practical
> solution?

The above benefits don't require "everybody is using the same package
dependency system". They accrue one machine at a time, by making *that
machine* less prone to the redundancy problems mentioned above.

They also are incremental, and are beneficial to move towards; that
is, even if the machine is using several package management systems,
any movement towards unifying the package management is a reduction in
duplication and hence a reduction in the associated problems.

> "Self-contained" has the merit that nobody else's changes are going
> to bugger about with my application on a customer's system.

That's nice for you, the programmer. Package management and proper
dependency declaration is a benefit to the customer (the one who owns
the machine, not the programmer) since they can upgrade each package
*once* per machine, and not have to hunt down all the places where a
previous version may still be installed simply because it was
convenient for the programmer.

Yes, this requires good management of APIs for libraries on the part
of the programmers of those libraries, and ensuring that a new version
with the same API maintains its expected behaviour. It also requires
that the programmer depending on those libraries declares dependencies
properly. It's working fine for many operating systems — even in the
absence of a universal package management system.

> The extra disk space is a small price to pay for that guarantee.

Hopefully you can discard this straw man argument and engage the
actual problems of redundant installations of identical code packages.

-- 
 \            "It's not what you pay a man, but what he costs you that |
  `\                                          counts."  -- Will Rogers |
_o__)                                                                  |
Ben Finney