On Sun 20 Jul 2014 11:12:17 Mike Gilbert wrote:
> On Sun, Jul 20, 2014 at 11:09 AM, Mike Gilbert wrote:
> > Is there some reason that we continue to maintain these as two
> > separate packages? It seems like the e2fsprogs ebuild could
> > build/install both the binaries and the libraries, and that would
> > probably prevent weird failures like this one.
> 
> > I see this in README.subset:
> Oops, hit send too quickly.
> 
> I see this in README.subset:
> 
> ---
> This distribution contains a subset of the e2fsprogs package; it
> contains the base libraries (ss, et, uuid, blkid) which may be used by
> other non-ext2-related applications.
> 
> This may be useful for non-Linux operating systems that need these
> libraries for GNOME, but who do not need the ext2/ext3 filesystem
> utilities.
> ---

e2fsprogs-libs was added because it provided those 4 libs which other packages 
were using and people did not like depending on sys-fs/e2fsprogs to get them 
(most significantly libuuid), which is not unreasonable.  since then, 
libuuid/libblkid have moved to util-linux, and the non-linux people again be 
hating on it.  see https://bugs.gentoo.org/278667.

deleting e2fsprogs-libs would busticate them badly.  at least the current 
situation allows us to keep the old version in the tree which provides 
libuuid.

the overhead here is not great imo (having done so for 6 years now), so i 
don't see a problem continuing it.

of course, the libuuid situation needs fixing up properly, but i don't have 
the inclination to sort it out, and the status-quo is still tolerable.

tl;dr: un-fsck the libuuid/libblkid situation and we probably can merge 
e2fsprogs-libs back in.  until then, not really.
-mike