Re: splitting source packages

[Axel Wagner <mero@merovius.de>]

Hi,

Neil Williams <codehelp@debian.org> writes:
> Atually, not particularly thinking of systemd at this point, but in
> *general* there is a good technical advantage to this approach:
> migrations & dependency control. It avoids the "fingers in every pie"
> problem common to a number of source packages in Debian.
> [...more stuff...]

This reasoning is basically "turtles all the way down". Let me give you
two examples to illustrate:

The first are the coreutils, often invoked as a good example of how to
do the unix-philosophy right. But if you look at pretty much any modern
implementation of (for example) ls, it certainly breaks with the
unix-philosophy *very* violently. It should just give you a listing of
all the files, but it also does:
• stat()ing (duplicated from stat(1))
• Sorting (duplicated from sort(1))
• Colorization
• Column-formatting
• --ignore,--hide (duplicated from grep(1))
• String escaping
It is also is unnecessarily intertwined with different software: At
least on my system there is --dired which only works with emacs. Now it
forces me to use emacs, instead of vim, or I have to implement this
functionality myself!
So really, ls should just offer a simple stable API to list files and
if you want colorized output, or more information about the files, you
can parse it's output and feed it to stat and/or grep and/or sort. So it
should basically just be a thin-wrapper around getdents(2).

Though, of course, getdents is just a syscall, so it is just part of
example number two: The linux userspace API. Because let's be honest: It
is next to impossible, to replace any part of the linux kernel or any
module, without having to constantly play catch-up. Because the kernel
does not offer any stable APIs to it's modules, you have to develop
modules in lockstep with the kernel. If the kernel would offer a stable
API, hardware-vendors could just develop their drivers against this API
and have it run for every kernel-version. Majorly painless updates for
proprietary drivers, finally! Though, of course, there is no good
reason, why a graphics-driver should stop at OpenGL (or similar) as a
stable-API for it's functionality. After all, this prevents me from
rolling my own OpenGL-implementation for this particular driver.

In both cases, the devs certainly acknowledged the need for a stable
API. But they had to choose one boundary where to provide this. So they
made their choice and committed to it. And one can disagree with these
choices (in both cases there are people who have very strong opinions
that these boundaries are indeed wrong), but ultimately it was the
choice of the maintainers, what level of modularity to provide.
The same goes for systemd: It actually *does* provide modularity and
stable APIs. In your opinion their choice of this boundary was
wrong. But boundaries are, in the end, arbitrary and it is ultimately up
to the maintainer of the package to decide, where they draw the line. At
the very least, if you want them to change their minds, it is up to
*you* to provide a justification why *your* choice of boundary is the
better one (i.e. no one argues *that* you need stable APIs. The question
is at what level and I have so far not seen any good arguments for a
different boundary).

Best,

Axel Wagner