It isn't possible to build an e2fsprogs via "make rpm" on SuSE and have it
install cleanly, because they split out some of the libraries into separate
packages.
We've got the current patch to the .spec file, but I'm open to discussion
if it is more desirable to change the .spec to continue to build separate
RPMs (though that is more of a distribution hassle and might need major
changes in the .spec file).
Index: e2fsprogs-1.40.2/e2fsprogs.spec.in
===================================================================
--- e2fsprogs-1.40.2.orig/e2fsprogs.spec.in
+++ e2fsprogs-1.40.2/e2fsprogs.spec.in
@@ -13,6 +13,10 @@
Url: http://e2fsprogs.sourceforge.net/
Prereq: /sbin/ldconfig
BuildRoot: %{_tmppath}/%{name}-root
+%if %{_vendor} == "suse"
+Obsoletes: libcom_err < %{version}
+Provides: libcom_err = %{version}
+%endif
%description
The e2fsprogs package contains a number of utilities for creating,
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
Andreas Dilger wrote:
> It isn't possible to build an e2fsprogs via "make rpm" on SuSE and have it
> install cleanly, because they split out some of the libraries into separate
> packages.
>
> We've got the current patch to the .spec file, but I'm open to discussion
> if it is more desirable to change the .spec to continue to build separate
> RPMs (though that is more of a distribution hassle and might need major
> changes in the .spec file).
>
FWIW, I also have an RFE assigned to me for RHEL/Fedora to split up our
e2fsprogs packages for libcom_err and libuuid... since many
non-filesystem things now require them. So, this is sort of going in
the opposite direction. :)
Any idea how many distros already split it out?
-Eric
> Index: e2fsprogs-1.40.2/e2fsprogs.spec.in
> ===================================================================
> --- e2fsprogs-1.40.2.orig/e2fsprogs.spec.in
> +++ e2fsprogs-1.40.2/e2fsprogs.spec.in
> @@ -13,6 +13,10 @@
> Url: http://e2fsprogs.sourceforge.net/
> Prereq: /sbin/ldconfig
> BuildRoot: %{_tmppath}/%{name}-root
> +%if %{_vendor} == "suse"
> +Obsoletes: libcom_err < %{version}
> +Provides: libcom_err = %{version}
> +%endif
>
> %description
> The e2fsprogs package contains a number of utilities for creating,
>
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Software Engineer
> Cluster File Systems, Inc.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sep 19, 2007 20:41 -0500, Eric Sandeen wrote:
> Andreas Dilger wrote:
> > It isn't possible to build an e2fsprogs via "make rpm" on SuSE and have it
> > install cleanly, because they split out some of the libraries into separate
> > packages.
> >
> > We've got the current patch to the .spec file, but I'm open to discussion
> > if it is more desirable to change the .spec to continue to build separate
> > RPMs (though that is more of a distribution hassle and might need major
> > changes in the .spec file).
>
> FWIW, I also have an RFE assigned to me for RHEL/Fedora to split up our
> e2fsprogs packages for libcom_err and libuuid... since many
> non-filesystem things now require them. So, this is sort of going in
> the opposite direction. :)
>
> Any idea how many distros already split it out?
I know Debian-based distros have done this for ages...
I'd also welcome someone with rpm-fu split it into separate packages.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
Andreas Dilger wrote:
> On Sep 19, 2007 20:41 -0500, Eric Sandeen wrote:
>> Andreas Dilger wrote:
>>> It isn't possible to build an e2fsprogs via "make rpm" on SuSE and have it
>>> install cleanly, because they split out some of the libraries into separate
>>> packages.
>>>
>>> We've got the current patch to the .spec file, but I'm open to discussion
>>> if it is more desirable to change the .spec to continue to build separate
>>> RPMs (though that is more of a distribution hassle and might need major
>>> changes in the .spec file).
>> FWIW, I also have an RFE assigned to me for RHEL/Fedora to split up our
>> e2fsprogs packages for libcom_err and libuuid... since many
>> non-filesystem things now require them. So, this is sort of going in
>> the opposite direction. :)
>>
>> Any idea how many distros already split it out?
>
> I know Debian-based distros have done this for ages...
>
> I'd also welcome someone with rpm-fu split it into separate packages.
I'd do this, my rpm-fu is still reasonably strong, though - I'm curious,
is there a compelling reason to split out just libcom-err? what about
libuuid? libblkid? e2fsprogs is a bit of a grab bag of things. What's
the rationale for the split?
-Eric
On Sep 20, 2007 15:22 -0500, Eric Sandeen wrote:
> I'd do this, my rpm-fu is still reasonably strong, though - I'm curious,
> is there a compelling reason to split out just libcom-err? what about
> libuuid? libblkid? e2fsprogs is a bit of a grab bag of things. What's
> the rationale for the split?
Well, I think its just "e2fsprogs needs (and largely developed) these things
and Ted doesn't want external package dependencies". There isn't a strong
reason to have them in a single package, especially as you say there are
more external packages that begin to depend on them, and e2fsprogs
(the libext2fs, e2fsck, etc. part) shouldn't necessarily be a "required"
package.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
On Thu, Sep 20, 2007 at 03:22:16PM -0500, Eric Sandeen wrote:
> I'd do this, my rpm-fu is still reasonably strong, though - I'm curious,
> is there a compelling reason to split out just libcom-err? what about
> libuuid? libblkid? e2fsprogs is a bit of a grab bag of things. What's
> the rationale for the split?
Nope, there isn't much rationale unless we also split out fsck, so
that people who don't want to use any ext 2/3/4 filesystems don't need
to install programs like e2fsck, mke2fs, libext2fs.so, etc.
The main reason why Debian did was more out of code wanking reasons
than anything else, as far as I know....
- Ted
On Thu, Sep 20, 2007 at 05:54:27PM -0400, Theodore Tso wrote:
> On Thu, Sep 20, 2007 at 03:22:16PM -0500, Eric Sandeen wrote:
> > I'd do this, my rpm-fu is still reasonably strong, though - I'm curious,
> > is there a compelling reason to split out just libcom-err? what about
> > libuuid? libblkid? e2fsprogs is a bit of a grab bag of things. What's
> > the rationale for the split?
>
> Nope, there isn't much rationale unless we also split out fsck, so
util-linux-ng is open for fsck :-)
Seriously, when we move fsck(8) to util-linux-ng we can compile this
util against libblkid **or** libvolume_id (udev). For example Suse prefers
libvolume_id, but RHEL/Fedora prefers libblkid, ..etc. The util-linux-ng
already has fsprobe API for both libraries -- port fsck(8) to
this API is 10mins work...
> that people who don't want to use any ext 2/3/4 filesystems don't need
> to install programs like e2fsck, mke2fs, libext2fs.so, etc.
mount(8) dependences on libblkid (or libvolume_id from udev).
I think sane downstream distributions are using separate binary
package(s) (RPM calls it subpackages) for libraries from e2fsprogs.
My $0.02...
Karel
PS. my workstation with Fedora 7:
# rpm -q --whatrequires libcom_err.so.2 libuuid.so.1 libblkid.so.1 | sort -u
apr-1.2.8-6
apr-util-1.2.8-7
cryptsetup-luks-1.0.5-4.fc7.1
curl-7.16.2-1.fc7
e2fsprogs-libs-1.40.2-2.fc7
evolution-data-server-1.10.3.1-2.fc7
gnome-vfs2-2.18.1-4.fc7
krb5-devel-1.6.1-4.fc7
krb5-libs-1.6.1-4.fc7
libpurple-2.1.1-1.fc7
neon-0.25.5-6
openssl-0.9.8b-14.fc7
pam_krb5-2.2.11-1
parted-1.8.6-4.fc7
subversion-1.4.3-4
--
Karel Zak <[email protected]>
On Mon, Sep 24, 2007 at 11:25:39AM +0200, Karel Zak wrote:
> >
> > Nope, there isn't much rationale unless we also split out fsck, so
>
> util-linux-ng is open for fsck :-)
It's something I'm considering, but at the moment I've got some higher
priority (ext4) work that I'm focusing on.
What would you think about moving libblkid and the libdisk from
xfsprogs into util-linux-ng? That's things that I've been batting
around doing, although that means we end up moving more libraries that
distros would probably want separated into different packages into
util-linux-ng....
- Ted
Theodore Tso wrote:
> On Mon, Sep 24, 2007 at 11:25:39AM +0200, Karel Zak wrote:
>>> Nope, there isn't much rationale unless we also split out fsck, so
>> util-linux-ng is open for fsck :-)
>
> It's something I'm considering, but at the moment I've got some higher
> priority (ext4) work that I'm focusing on.
>
> What would you think about moving libblkid and the libdisk from
> xfsprogs into util-linux-ng? That's things that I've been batting
> around doing, although that means we end up moving more libraries that
> distros would probably want separated into different packages into
> util-linux-ng....
Heh, sounds a little like a prisoner exchange... "we'll give up libblkid
& libcom_err if you give up libdisk" :)
Seriously, though, that all sounds like a pretty good idea to me,
especially since e2fsprogs has been making noise about utilizing some of
the functionality in xfsprogs (stripe discovery etc).
-Eric
On Mon, Sep 24, 2007 at 08:40:36AM -0400, Theodore Tso wrote:
> On Mon, Sep 24, 2007 at 11:25:39AM +0200, Karel Zak wrote:
> > >
> > > Nope, there isn't much rationale unless we also split out fsck, so
> >
> > util-linux-ng is open for fsck :-)
>
> It's something I'm considering, but at the moment I've got some higher
> priority (ext4) work that I'm focusing on.
That's nothing urgent. This migration shouldn't be so difficult -- I
think we should provide at least one release when the util is in both
packages -- defaultly disabled in e2fsprogs and enabled in
util-linux-ng. It's probably better that trying to synchronize
releases of both packages.
> What would you think about moving libblkid and the libdisk from
> xfsprogs into util-linux-ng? That's things that I've been batting
I have no problem with this idea, but I'd like to invite Kay Sievers
(udev) to this discussion. I think the best step will be merge
libblkid and libvolume_id to the one independent project. There is
few technical problems with this idea, but nothing insolvable.
Now we duplicate a lot of FS probe code in libblkid, libvolume_id and
libdisk.
Yes, it's long-term task, but it's good direction (IMHO).
Karel
--
Karel Zak <[email protected]>
Eric Sandeen <[email protected]> writes:
> Andreas Dilger wrote:
>> On Sep 19, 2007 20:41 -0500, Eric Sandeen wrote:
>>> Andreas Dilger wrote:
>>>> It isn't possible to build an e2fsprogs via "make rpm" on SuSE and have it
>>>> install cleanly, because they split out some of the libraries into separate
>>>> packages.
>>>>
>>>> We've got the current patch to the .spec file, but I'm open to discussion
>>>> if it is more desirable to change the .spec to continue to build separate
>>>> RPMs (though that is more of a distribution hassle and might need major
>>>> changes in the .spec file).
>>> FWIW, I also have an RFE assigned to me for RHEL/Fedora to split up our
>>> e2fsprogs packages for libcom_err and libuuid... since many
>>> non-filesystem things now require them. So, this is sort of going in
>>> the opposite direction. :)
>>>
>>> Any idea how many distros already split it out?
>>
>> I know Debian-based distros have done this for ages...
>>
>> I'd also welcome someone with rpm-fu split it into separate packages.
>
> I'd do this, my rpm-fu is still reasonably strong, though - I'm curious,
> is there a compelling reason to split out just libcom-err? what about
> libuuid? libblkid? e2fsprogs is a bit of a grab bag of things. What's
> the rationale for the split?
The Suse split out of library packages has been enforced by our new library
packaging policy[1]. I think debian has a similar policy [2].
In openSUSE the splitted out library packages are
libblkid1
libcom_err2
libext2fs2
libuuid1
with the corresponding development packages named with the -devel
postfix but without the soname version appendix. There is currently also
a dummy e2fsprogs-devel package for backwards compatibility.
I am not sure how other RPM based distributions will handle this and
if it is worth the effort to keep track of all this in one specfile.
If needed I could take care for the Suse specific stuff.
Matthias
[1] http://en.opensuse.org/Shared_Library_Packaging_Policy
[2] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
On Tue, 2007-09-25 at 11:14 +0200, Karel Zak wrote:
> On Mon, Sep 24, 2007 at 08:40:36AM -0400, Theodore Tso wrote:
> > On Mon, Sep 24, 2007 at 11:25:39AM +0200, Karel Zak wrote:
> > > >
> > > > Nope, there isn't much rationale unless we also split out fsck, so
> > >
> > > util-linux-ng is open for fsck :-)
> >
> > It's something I'm considering, but at the moment I've got some higher
> > priority (ext4) work that I'm focusing on.
>
> That's nothing urgent. This migration shouldn't be so difficult -- I
> think we should provide at least one release when the util is in both
> packages -- defaultly disabled in e2fsprogs and enabled in
> util-linux-ng. It's probably better that trying to synchronize
> releases of both packages.
>
> > What would you think about moving libblkid and the libdisk from
> > xfsprogs into util-linux-ng? That's things that I've been batting
>
> I have no problem with this idea, but I'd like to invite Kay Sievers
> (udev) to this discussion. I think the best step will be merge
> libblkid and libvolume_id to the one independent project.
Oh, I would be fine with putting that in util-linux. Mount is the most
critical user, so it has it's place there from my point of view. And
having mount and fsck in util-linux, sharing the fsprobing code and
fstab-parsing code sounds great to me.
> There is
> few technical problems with this idea, but nothing insolvable.
I'm all for doing this, and don't see any real problem with that. I
talked to Ted a few weeks ago when we met in person about this already.
> Now we duplicate a lot of FS probe code in libblkid, libvolume_id and
> libdisk.
>
> Yes, it's long-term task, but it's good direction (IMHO).
It is, and we are not providing a real value to the users by providing
both of these libs at the same time. :)
But udev has a very different requirement for probing filesystems.
Unlike non-udev systems, we can't accept any hidden policy inside a
library. We just want to pass a byte stream to the lib, and get back
what exactly is in _this_ byte stream. There must be no chaching, no
devmapper logic, no stat()'ing in /dev, no reading of /proc/partitions,
no ioctl()'s, no hidden decisions, nothing. None of these actions is
acceptable to be done by the library itself, if udev is used. We need
pure mechanics, no policy. We also need an API that allows to specify
the size of the stream and the probing offset. And we don't want to
iterate over tags, need the filesystem version information, the raid
metadata probing, and the classification volume_id provides.
That means that we could replace the "low-level" part of libblkid with
volume_id code, and keep the current API of blkid, but offer some of the
low-level functionality for udev. Or we would implement the relevant
parts and probers in blkid, and add a new API to access the low-level
part directly.
Note, that even with only one fsprobing library, util-linux would still
need to behave differently on a udev system, because we can't afford to
maintain a cache file, or search for anything else at event time, on
systems with 20.000 hard disks connected. But systems without udev will
obviously need the "search all devices" functionality of blkid to find
labels and uuid's.
Let me know what you think how go ahead with this, I'm all for doing
this sooner than later.
Cheers,
Kay
On Tue, Sep 25, 2007 at 12:11:23PM +0200, Kay Sievers wrote:
> On Tue, 2007-09-25 at 11:14 +0200, Karel Zak wrote:
> > Now we duplicate a lot of FS probe code in libblkid, libvolume_id and
> > libdisk.
> >
> > Yes, it's long-term task, but it's good direction (IMHO).
>
> It is, and we are not providing a real value to the users by providing
> both of these libs at the same time. :)
>
> But udev has a very different requirement for probing filesystems.
> Unlike non-udev systems, we can't accept any hidden policy inside a
> library. We just want to pass a byte stream to the lib, and get back
> what exactly is in _this_ byte stream. There must be no chaching, no
> devmapper logic, no stat()'ing in /dev, no reading of /proc/partitions,
> no ioctl()'s, no hidden decisions, nothing. None of these actions is
> acceptable to be done by the library itself, if udev is used. We need
> pure mechanics, no policy. We also need an API that allows to specify
> the size of the stream and the probing offset. And we don't want to
> iterate over tags, need the filesystem version information, the raid
> metadata probing, and the classification volume_id provides.
Technical details :-)
> That means that we could replace the "low-level" part of libblkid with
> volume_id code, and keep the current API of blkid, but offer some of the
> low-level functionality for udev. Or we would implement the relevant
> parts and probers in blkid, and add a new API to access the low-level
> part directly.
I don't see a problem to provide low-level and high-level interface in
same library. The low-level stuff (fsprobe code) is still same.
Things like a cache are discussable -- for example resolve LABEL/UUID
on system with udev is faster by /dev/disk/by-*. I think a good
library has to be smart enough to found the fastest way how translate
LABEL/UUID to device name.
But, it's too early to talk about details.
> Let me know what you think how go ahead with this, I'm all for doing
> this sooner than later.
Cool. I'd like to create libfsprobe as an independent project. Or is
there any advantage to merge everything to util-linux-ng? I don't
think so.
Karel
--
Karel Zak <[email protected]>
On Tue, Sep 25, 2007 at 02:34:54PM +0200, Karel Zak wrote:
> > That means that we could replace the "low-level" part of libblkid with
> > volume_id code, and keep the current API of blkid, but offer some of the
> > low-level functionality for udev. Or we would implement the relevant
> > parts and probers in blkid, and add a new API to access the low-level
> > part directly.
>
> I don't see a problem to provide low-level and high-level interface in
> same library. The low-level stuff (fsprobe code) is still same.
Agreed, one interface and one code base for determining "what is this
filesystem is a good thing".
> Things like a cache are discussable -- for example resolve LABEL/UUID
> on system with udev is faster by /dev/disk/by-*. I think a good
> library has to be smart enough to found the fastest way how translate
> LABEL/UUID to device name.
It depends on what you're doing, actually. If you want to resolve
multiple UUID's, it will be faster to use the cache, since it's in
memory. And the blkid cache will allow you to do things like find all
devices with a particular filesystem type, etc. And although blkid
doesn't do this now, it's a more flexible model for handling things
like "to find the ext3 journal with UUID=XXXX-...-XXXX", use this
iSCSI device at this IP address. Assuming that you can always probe
all 30,000 devices and populate /dev/disk/by-* at boot time is not
necessarily something that I would consider scalable; if you have
hundreds of thousands of LUN's connected to a storage array that
aren't mounted at boot time, and only mounted on demand when a
particular LUN is needed, I think the udev model doesn't fit all that
well.
> Cool. I'd like to create libfsprobe as an independent project. Or is
> there any advantage to merge everything to util-linux-ng? I don't
> think so.
My main concern is avoiding what the "GNOME library problem". Huge
numbers of independent projects makes build dependencies incredibly
painful. And of course, any time we do this kind of factoring we need
to keep the interfaces stable. In userspace, with published, stable
API's are not nonsense, but an absolute and unconditional requirement.
- Ted
On Tue, 2007-09-25 at 14:34 +0200, Karel Zak wrote:
> On Tue, Sep 25, 2007 at 12:11:23PM +0200, Kay Sievers wrote:
> > On Tue, 2007-09-25 at 11:14 +0200, Karel Zak wrote:
> > > Now we duplicate a lot of FS probe code in libblkid, libvolume_id and
> > > libdisk.
> > >
> > > Yes, it's long-term task, but it's good direction (IMHO).
> >
> > It is, and we are not providing a real value to the users by providing
> > both of these libs at the same time. :)
> >
> > But udev has a very different requirement for probing filesystems.
> > Unlike non-udev systems, we can't accept any hidden policy inside a
> > library. We just want to pass a byte stream to the lib, and get back
> > what exactly is in _this_ byte stream. There must be no chaching, no
> > devmapper logic, no stat()'ing in /dev, no reading of /proc/partitions,
> > no ioctl()'s, no hidden decisions, nothing. None of these actions is
> > acceptable to be done by the library itself, if udev is used. We need
> > pure mechanics, no policy. We also need an API that allows to specify
> > the size of the stream and the probing offset. And we don't want to
> > iterate over tags, need the filesystem version information, the raid
> > metadata probing, and the classification volume_id provides.
>
> Technical details :-)
What do you miss, these are all technical details. :) In simple words,
we need a completely policy-free, not try-to-be-smart in any sense set
of functions to identify a bytestream by magic bytes.
> > That means that we could replace the "low-level" part of libblkid with
> > volume_id code, and keep the current API of blkid, but offer some of the
> > low-level functionality for udev. Or we would implement the relevant
> > parts and probers in blkid, and add a new API to access the low-level
> > part directly.
>
> I don't see a problem to provide low-level and high-level interface in
> same library. The low-level stuff (fsprobe code) is still same.
Yes, it would be the same.
> Things like a cache are discussable -- for example resolve LABEL/UUID
> on system with udev is faster by /dev/disk/by-*. I think a good
> library has to be smart enough to found the fastest way how translate
> LABEL/UUID to device name.
This is exactly what I mean and need to avoid. The library should not
try to be smart if not explicitly asked for. It should definitely not
"try to find something out". The caller is smart enough in this case.
> But, it's too early to talk about details.
>
> > Let me know what you think how go ahead with this, I'm all for doing
> > this sooner than later.
>
> Cool. I'd like to create libfsprobe as an independent project. Or is
> there any advantage to merge everything to util-linux-ng? I don't
> think so.
Hmm, only if you reaqlly don't want to pull it in util-linux, we could
have it as a separate tree. I still think util-linux is the best place,
because the most important user of it is mount/fsck. It's your call, I
would have no problem sending patches against util-linux. :)
Kay
On Tue, Sep 25, 2007 at 10:25:50PM +0200, Kay Sievers wrote:
> On Tue, 2007-09-25 at 14:34 +0200, Karel Zak wrote:
> > On Tue, Sep 25, 2007 at 12:11:23PM +0200, Kay Sievers wrote:
> > > On Tue, 2007-09-25 at 11:14 +0200, Karel Zak wrote:
> > > > Now we duplicate a lot of FS probe code in libblkid, libvolume_id and
> > > > libdisk.
> > > >
> > > > Yes, it's long-term task, but it's good direction (IMHO).
> > >
> > > It is, and we are not providing a real value to the users by providing
> > > both of these libs at the same time. :)
> > >
> > > But udev has a very different requirement for probing filesystems.
> > > Unlike non-udev systems, we can't accept any hidden policy inside a
> > > library. We just want to pass a byte stream to the lib, and get back
> > > what exactly is in _this_ byte stream. There must be no chaching, no
> > > devmapper logic, no stat()'ing in /dev, no reading of /proc/partitions,
> > > no ioctl()'s, no hidden decisions, nothing. None of these actions is
> > > acceptable to be done by the library itself, if udev is used. We need
> > > pure mechanics, no policy. We also need an API that allows to specify
> > > the size of the stream and the probing offset. And we don't want to
> > > iterate over tags, need the filesystem version information, the raid
> > > metadata probing, and the classification volume_id provides.
> >
> > Technical details :-)
>
> What do you miss, these are all technical details. :) In simple words,
> we need a completely policy-free, not try-to-be-smart in any sense set
> of functions to identify a bytestream by magic bytes.
Yes, I've read libvolume_id code and I good understand what you mean.
> > Cool. I'd like to create libfsprobe as an independent project. Or is
> > there any advantage to merge everything to util-linux-ng? I don't
> > think so.
>
> Hmm, only if you reaqlly don't want to pull it in util-linux, we could
> have it as a separate tree. I still think util-linux is the best place,
> because the most important user of it is mount/fsck. It's your call, I
> would have no problem sending patches against util-linux. :)
OK, Ted has same opinion and I'm not so stubborn... Let's use
util-linux-ng.
(I think we can continue with this topic at util-linux-ng mailing
list only.)
Karel
--
Karel Zak <[email protected]>
On Tue, Sep 25, 2007 at 10:25:50PM +0200, Kay Sievers wrote:
> > Technical details :-)
>
> What do you miss, these are all technical details. :) In simple words,
> we need a completely policy-free, not try-to-be-smart in any sense set
> of functions to identify a bytestream by magic bytes.
Which is exactly what mount and fsck should be doing aswell for a given
device. In addition they also have the need to find a device if the
fstab line is identified with LABEL and UUID. But these are rather
separate issues.
> Hmm, only if you reaqlly don't want to pull it in util-linux, we could
> have it as a separate tree. I still think util-linux is the best place,
> because the most important user of it is mount/fsck. It's your call, I
> would have no problem sending patches against util-linux. :)
Shipping this with util-linux would make some sense. Then again I'm
a big fan of not mixing up shared libraries and binaries in the same
package. This just means the distros have to split them into separate
packages again.