On Mon, 2016-02-22 at 09:54 -0500, Courtney Pacheco wrote:
If possible, I'd like some feedback on the work I did. Comments
and
criticism are more than welcomed! I realize there may be some
controversy in terms of what I chose to remove and what I chose to turn
into weak dependencies, but I would like to hear your thoughts either way.
Removing tzdata seems like a bad idea. I think a small amount of code
change could make the cost of keeping tzdata much lower. Virtually all
of the tzdata files are less than 4 kilobytes, so most of the on-disk
storage cost is block size overhead:
dmt:~% du -s --apparent-size /usr/share/zoneinfo
1720 /usr/share/zoneinfo
dmt:~% du -s /usr/share/zoneinfo
4780 /usr/share/zoneinfo
Possible options include:
a) Glue all the compiled zone info together in a single file, teach
glibc and friends about it
b) Glue the zone info together in a romfs image, mount it from a
systemd unit
c) Both of the above: glue them all together in a romfs, add a
fuse/overlay fs to expose the individual files
d) Mount a zoneinfo fs exported from the host
A somewhat similar criticism applies to removing gconv. Pretending that
applications don't have to deal with multiple character encodings is
likely to be wrong, and we don't currently have any metadata to track
whether a binary calls iconv() so there's no way to express the need
for the gconv modules. Here again, most of these libraries are
relatively small, and gluing them all together would be a decent size
win:
dmt:/usr/lib64/gconv% du -c *.so | tail -1
7352 total
dmt:/usr/lib64/gconv% du --apparent-size -c *.so | tail -1
6448 total
dmt:/usr/lib64/gconv% size -t *.so | tail -1
4778516 161368 2016 4941900 4b684c
(TOTALS)
Both things are possible here: we could teach rpm's find-requires to
know about iconv, _and_ link all the gconv modules together.
- ajax