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>