A few weeks ago, Lars and I had a discussion: wouldn't it be nice if, across the whole of Debian, applications stopped writing to arbitrary dot-files in your home directory (e.g. ~/.someapp) and instead abided by the XDG Base Directory Specification?

Assuming that there was Debian-wide consensus that this was a good idea, in theory it could be achieved. The main problem would be that many of the upstream authors of the software we package would not accept the change. Consequently, Debian would be left carrying the patches.

We generally try to remain as close to upstream's code as possible and shy away from carrying too many patches in too many packages. The ideal lifecycle for a patch is for it to be accepted upstream. Patches are a burden for packagers, and we don't have enough packagers or packager time (or both).

Contrast this to OpenBSD. I know very little about the BSDs, and what little I do know I've mostly gleaned from the excellent blog posts by Ted Unangst, but my understanding is that when they import some software into their main project, their mental model appears to be closer to that of a fork of the upstream software than the way Debian (and most Linux distributions) operate. The entire OpenBSD Operating System is in a single (CVS!) version control repository. When some software is imported to the core Operating System, that software's source is copied into place within the tree and from that point forward is managed as part of the whole.

(OpenBSD also have a separate source code collection called "ports", which is managed in a different manner which is much closer to a Linux distribution's notion of packaging, but I won't cover that further here.)

If they decided that a distribution-wide project was worthy, they would have no hesitation in making that change across all the software in their Operating System. Their focus is on consistency and they seem to maintain that focus rather than thinking about packages in relative isolation.

Although I do appreciate the practical problem of Debian managing a lot of patches, I am sometimes envious of OpenBSD's approach and corresponding perspective. Although I really do not miss CVS.

Thanks to Ryan Freeman for proof-reading this blog post. The remaining errors are mine.

Comments

Atom
comment 1

Yes, it would be nice but somewhere needs the line to be drawn. And patches to make software compatible to "XDG Base Directory Specification" are not trivial (because there is also a colon separated list of files in XDG_CONFIG_DIRS).

Furthermore, the "XDG Base Directory Specification" only solves a part of the problem (reading config files) but makes writing config files more difficult. (How should the administrator know the content of XDG_CONFIG_DIRS).

Elektra is a more complete solution which also solves the problem of how to modify settings. If wanted, it supports the XDG specification. Disclaimer: I am an author of the software.

The idea of Elektra is to draw the line at API level. Even if applications do not want to use Elektra, someone else can implement their config API with Elektra (called bindings). For example, we have (experimental!) bindings for GSettings or "open". So applications with the "open" binding doing open ("~/.myconfigfile") would get a file generated from Elektra.

Comment by Markus Raab,

✏ comment on this page (Help on commenting) ⏳