| e2fsprogs for Debian |
| ==================== |
| |
| e2fsprogs includes the uuidgen(1) program, although it is not directly |
| to e2fsprogs - it would belong to the libuuid package, but the uuid |
| shared lib is currently part of the e2fsprogs package. See below for |
| more details. |
| |
| |
| Here's the documentation for the Conflicts/Provides fields: |
| |
| * old dump and quota packages used to depend on old (libc5) e2fsprogs |
| itself, as it contained the shared libs. We must conflict with these |
| incompatible versions. |
| |
| |
| * All -g package names were a transient experiment during hamm |
| development. |
| |
| |
| * Here's the reasonning for not moving the libs outside of the |
| e2fsprogs package (this may be partly obsolete): |
| |
| If we have: |
| |
| e2fsprogs_1.10-2 is essential |
| |
| e2fsprogs_1.10-11 is essential |
| predepends on comerr2g |
| |
| comerr2g_2.0-1.10-11: |
| is not essential |
| conflicts with e2fsprogs_1.10-2 |
| |
| ...then e2fsprogs_1.10-11 can't be installed before comerr2g because |
| of the predependency, and comerr2g cannot be installed before |
| e2fsprogs_1.10-11 because of the conflict. |
| |
| This totally comes from the fact that e2fsprogs was initially built as |
| an *essential package with shared libs*. |
| |
| My initial solution, namely changing the predependency into a simple |
| dependency, turns out to be a system-integrity problem: |
| |
| $ dpkg -i e2fsprogs_1.10-11*deb comerr2g_2.0-1.10-11*deb |
| |
| ...will, if comerr2g fails to unpack or configure, let e2fsprogs in an |
| unusable state. |
| |
| |
| * This raises the problem that most of these libs are general-purpose |
| libs, and will be used by more and more packages. The lib-dependency |
| mechanism requires for proper fonctionning that we keep track of these |
| libs changing version, as well as infos such as libc5/6 issues. |
| |
| The standard way to do it is using standalone packages for those libs, |
| which is not possible here (see above). |
| |
| My solution in this case is the use of the following virtual packages: |
| |
| libss2, libcomerr2, libe2p2, libuuid1, libext2fs2 |
| |
| These are automatically referenced thanks to the shlibs file. They |
| are currently provided by e2fsprogs. |
| |
| |
| * Additionally, we must add to the shlibs file a dep on "e2fsprogs (>= |
| <current-version>)", so that programs using new functions from those |
| libs will not break (see #139274). Note that this will be superceeded |
| by versionned Provides: when they will come in dpkg. |
| |
| We can see the reality of the problem: |
| |
| $ diff <(nm -D 1.18/lib/libuuid.so.1 | cut -c10- | grep -v ^U) \ |
| <(nm -D 1.27/lib/libuuid.so.1 | cut -c10- | grep -v ^U) |
| 3a4 |
| > w __cxa_finalize |
| 6a8,9 |
| > T __udivdi3 |
| > T __umoddi3 |
| |
| <=== Actually, there are **no** API changes in libuuid between |
| e2fsprogs 1.27 and 1.18. The observant reader will notice |
| that the "reality of the problem" show above shows symbol |
| names which are are prefixed with "__". This means no program |
| should be using them. In point of fact, these are functions |
| created by gcc, and the incompatibility reported in #139274 |
| was much more likely casued by glibc or gcc incompatibilities, |
| not changes in the libuuid library. Hence, I am removing the |
| shlibs hack, because it does far more harm than it does good. |
| (Next time, *please* consult me before making changes like |
| this.) |
| -- Theodore Ts'o, tytso@mit.edu. |
| |
| |
| * e2fsprogs still Provides/Conflicts with e2fslibsg to allow upgrading |
| from pre 1.10-13 releases (from unstable hamm). This does not seem to |
| be possible for ss2g and comerr2g for some still-to-be-investigated |
| reason. |
| |
| Yann Dirson <dirson@debian.org> |