Russ Allbery wrote: > This is more of a high-level design intuition that stems from some basic > architectural principles, such as "dpkg should be the authority for what > Debian installs on the file system so that it can ensure global > consistency." > > But to give you a concrete answer, here are the sorts of things that come > to mind even after this transition is complete in Debian: > > * Old packages that still use aliased paths installed on current systems. > * Locally-built packages with /bin paths in data.tar.gz. > * Weird local symlinks to move files around in the file system. > * Some unforseen future transition where we want to merge two directories.
Indeed. In the history of Debian, we've had - The /usr/doc -> /usr/share/doc transition - The /usr merge - Various package-specific transitions from an old directory to a new, where it'd be convenient for the package to install a transitional symlink rather than support both paths internally - Local sysadmins who might want to move something to a different directory (whether for space constraints or local package organization) and have dpkg actually understand what they're doing - In the future, I wouldn't be surprised if someone *attempts* to merge /usr/sbin -> /usr/bin one day. It'd be incredible if those were as simple as building and installing a package that installs a symlink in its data.tar where other packages install a directory. (And possibly including some metadata that says "yes, I really do mean to install a symlink redirect for a directory, this isn't just a file conflict mistake".) > I think we have an entire project full of people with expert skills, > including some truly impressive C programmers, and I find our inability to > muster those resources to improve *the* foundational program on which the > work of the entire distribution rests on, in a way that meets a very high > quality bar and is sustainable for the project, to be disappointing. I'm > not assigning blame; I'm simply saying that it makes me sad that the > assumption is that only Guillem alone is able to work on this project and > therefore its success is constrained by his available time. I agree with you that this is disappointing. > I have some concerns that Guillem is trying to boil the ocean and he's > missing some viable incremental approach, but this is only a vague concern > and I absolutely do not have the expertise in dpkg to argue that case. > Clearly Guillem has convinced himself that it is the correct approach and > he is an expert in this area, so he is probably correct and I am probably > wrong. I think this paragraph very much captures why a project with many expert developers in a variety of different areas believes (whether correctly or incorrectly) that their help would not be welcomed. (And to be clear, I really do mean "correctly or incorrectly" here; please don't take this as presupposing the answer to that question.) dpkg is trying to solve an *incredibly* complex problem, with very demanding constraints, and decades of historical expectations and compatibility requirements, in addition to added constraints from possible maintainer preferences and tastes. And as a project, we have not solved the problem of either documenting or simplifying enough of those to the point of inviting contribution.
