I'm using Stow 2.2.0 and tried to install e2fsprogs 1.41.14. I'm building in a halfly installed LFS environment, using Stow as the package manager. I configure packages with --prefix=/usr and install them in a subdirectory in /pkg. These are the steps I did to stow e2fsprogs (being in the distribution directory):

mkdir build ; cd build
PKG_CONFIG=/tools/bin/true LDFLAGS=-lblkid ../configure --prefix=/usr --with-root-prefix="" --enable-elf-shlibs --disable-libblkid --disable-libuuid --disable-uuidd --disable-fsck
make
DESTDIR=/pkg/e2fsprogs make install
DESTDIR=/pkg/e2fsprogs make install-libs
cd /pkg
stow -t / e2fsprogs

PKG_CONFIG was needed because at that point pkg-config was not installed. After running the stow command it reported the absolute links and aborted, so I removed them and replaced them with relative ones:

cd /pkg/e2fsprogs/usr/lib
rm libext2fs.so
ln -s ../../lib/libext2fs.so.2 libext2fs.so

I repeated this with the other symlinks Stow reported. Then I reran the stow command, this time with success.

Stow currently checks for absolute symlinks and stops stowing if it finds some. This behaviour clashes with some packages such as e2fsprogs and with the Debian Policy for symbolic links (section 10.5).

Example: I recently tried to install e2fsprogs.  I made an 'DESTDIR=/pkg/e2fsprogs make install' and then tried to run 'cd /pkg ; stow -t / e2fsprogs'.  Stow then denied operation complaining about absolute symlinks in the package to stow (in case of e2fsprogs /usr/lib/libext2fs.so => /lib/libext2fs.so.2 amongst others).  I made Stow to run successful by removing the symlink and making a relative one from libext2fs.so in /pkg/e2fsprogs/usr/lib to ../../lib/libext2fs.so.2.  It is however legitimate (according to Debian policy) for packages to create absolute symlinks as long as the symlink points to another top-level directory.

I'd suggest fixing Stow in this regard, so Stow would only complain if the absolute symlink points to a file in the same top-level directory (e.g. from /usr/... to /usr/...).