Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 14:06 UTC (Mon) by ebassi (subscriber, #54855)
In reply to: Poettering: Revisiting how we put together Linux systems by mrdocs
Parent article: Poettering: Revisiting how we put together Linux systems

One thing no one has brought up is in my experience, most developers are not really good as packagers.

shockingly, when "packaging" is a set of policies that change in order to ensure that "packaging" cannot be automated like it should, in order to keep around fiefdoms and OCD-level of control over them, people actually writing the software have issues complying with all the little rules and incompatibilities.

Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 19:02 UTC (Mon) by tao (subscriber, #17563) [Link]

Debian (I'm a DD) has a lot of packaging policies. But I'd also argue (I'm of course biased) that we have the most consistent distribution. Some of Debian's policies are very strictly enforced, others are merely suggestions on how to ensure a better experience for the end user.

The policies are there to make sure that all packages can either co-exist or, in cases where they're by nature conflicting, said conflicts are formalised in terms of package dependencies/conflicts/etc.

Sure, there are things you'll need to do manually (generally only once per package though, unless the package drastically changes), but for the average Debian developer most of the effort is spent either on:

* Fixing things that should've been done upstream (symbol versioning, portability, ... Even things you'd think would obviously included with every piece of software, such as manual pages)

* Backporting fixes when upstream cannot be bothered to release security fixes for older versions of their software

* Modifying code to be able to run with older versions of libraries, to ease situations where software A, B, C all depend on library version 2.4 but software D depends on library version 2.5

* Reinstating functionality that upstream has removed with the intent to replace it with something better (but have not yet done so)

* Ensuring that the end product is actually legally redistributable (care must always be taken so that the license of software A is compatible with the licenses for library B, C, D, E, ...)

Most of all though, the main reason upstream developers are generally not good packagers is that the developer has software A to care for (and only needs to make sure that it works as long as its dependencies are available), but the packager needs to ensure not only that A works, but also that A doesn't cause breakage in totally unrelated packages B, C, D, ...

The packagers also need to worry about annoying little details such as unrelated software sharing the same name (git, node, epiphany for instance).

PS: I cannot speak for other distributions, but none of the packaging policies in Debian change to "ensure that packaging cannot be automated". If you have something you believe to be a counter-example, please share.