You are correct [LWN.net]

You are correct

Posted Feb 1, 2008 3:57 UTC (Fri) by salimma (subscriber, #34460)
In reply to: You are correct by jd
Parent article: Why companies don't support Debian (LinuxWatch)

"Ubuntu's packages aren't compiled against a uniform environment, creating some fascinating
dependency conflicts."

Dependency conflicts are unavoidable in some cases, due to package churn. To avoid it you'd
have to state that the packages that ship with the distribution is not allowed to break API
during the lifecycle of that distribution.

(Log in to post comments)

Yes.

Posted Feb 1, 2008 7:13 UTC (Fri) by jd (guest, #26381) [Link]

For 100% avoidance, yes, you are right. For a superior level of avoidance, it should be sufficient for the following conditions to be met:

Package configuration files would need to be generated, not static. One way to do this would be to:
1. Examine non-local dependency information in the makefiles
2. Examine linkage information in the compiled binaries
3. Examine build configuration files for libraries and utilities not referenced in the first two steps
4. Reverse lookup what external packages are installed that supply the requisite headers, libraries and utilities
Dependency trees would need to be rebuilt. One way to do this would be to:
1. Regard each dependency as a leaf node of an n-ary tree. Recursively apply this step until all root nodes for all trees have been obtained.
2. If a package has changed OR any package further up the tree has been recompiled, the package is recompiled.
3. If a package has not been recompiled, the only important dependent package is the one already known on that dependency tree. The previous step is then applied to that package alone.
4. If a package has been recompiled, then all packages which depend on it must be identified and recompiled. Since a package is only skipped if a dependency has not been recompiled, this step alone is recursively applied until there are no further dependencies on anything in the tree that has been built.

This obviously doesn't work if there is a break in an API. Anything past a breakage point cannot be refreshed in this way. Not if you use LSB and dynamic linking. You could do it if you had version isolation (a working library can always be present) -or- if the build machine used version isolation and static linking on old libraries to hide legacy details.

There is, of course, another option - controlled slippage. Have a declared distro standard that libraries and utilities should provide a means of emulating old APIs some sensible number of generations back, and that packages have some appropriate time to be fixed or have a distro patch that brings them up to the active API. This doesn't constrain anyone in practice. If anything, it constrains fewer people, as it eliminates many constraints on the distro maintainers and users.

These are heavyweight solutions, yes, which means that you'd need some serious manpower (and compute power) on some of the most tedious areas of packaging. There simply aren't the resources to do anything like this without some corporate involvement, but since these are the sorts of things corporations do well (whereas coding isn't) and like (applications working well together), this isn't too much of a problem. It doesn't impact developers or their freedom, because that's not where the problem lies, but does boost areas of usability that are currently a pain.