1 |
On Sun 20 Jul 2014 11:12:17 Mike Gilbert wrote: |
2 |
> On Sun, Jul 20, 2014 at 11:09 AM, Mike Gilbert wrote: |
3 |
> > Is there some reason that we continue to maintain these as two |
4 |
> > separate packages? It seems like the e2fsprogs ebuild could |
5 |
> > build/install both the binaries and the libraries, and that would |
6 |
> > probably prevent weird failures like this one. |
7 |
> |
8 |
> > I see this in README.subset: |
9 |
> Oops, hit send too quickly. |
10 |
> |
11 |
> I see this in README.subset: |
12 |
> |
13 |
> --- |
14 |
> This distribution contains a subset of the e2fsprogs package; it |
15 |
> contains the base libraries (ss, et, uuid, blkid) which may be used by |
16 |
> other non-ext2-related applications. |
17 |
> |
18 |
> This may be useful for non-Linux operating systems that need these |
19 |
> libraries for GNOME, but who do not need the ext2/ext3 filesystem |
20 |
> utilities. |
21 |
> --- |
22 |
|
23 |
e2fsprogs-libs was added because it provided those 4 libs which other packages |
24 |
were using and people did not like depending on sys-fs/e2fsprogs to get them |
25 |
(most significantly libuuid), which is not unreasonable. since then, |
26 |
libuuid/libblkid have moved to util-linux, and the non-linux people again be |
27 |
hating on it. see https://bugs.gentoo.org/278667. |
28 |
|
29 |
deleting e2fsprogs-libs would busticate them badly. at least the current |
30 |
situation allows us to keep the old version in the tree which provides |
31 |
libuuid. |
32 |
|
33 |
the overhead here is not great imo (having done so for 6 years now), so i |
34 |
don't see a problem continuing it. |
35 |
|
36 |
of course, the libuuid situation needs fixing up properly, but i don't have |
37 |
the inclination to sort it out, and the status-quo is still tolerable. |
38 |
|
39 |
tl;dr: un-fsck the libuuid/libblkid situation and we probably can merge |
40 |
e2fsprogs-libs back in. until then, not really. |
41 |
-mike |