allow about->"software licenses" to read gzip'd files to reclaim some more disk space
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| livecd-rootfs (Ubuntu) |
Triaged
|
Wishlist
|
Unassigned | ||
| ubuntu-system-settings (Ubuntu) |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
/usr/share/doc is stripped down to only the copyright files and yet...
$ du -sh /usr/share/doc
19M /usr/share/doc
Compressing even just the copyrights gives an appreciable gain:
$ cp -a /usr/share/doc /tmp/foo
$ find /tmp/foo/ -type f -exec gzip -9 {} \; && du -sh /tmp/foo
5.5M /tmp/foo
A saving of 13+ Meg!
However, for this to be useful, the software licenses view would need to be able to read gzip'ed files.
= Performance =
Currently, reading a *single* copyright from the software licenses screen is slow (~1-2 seconds to read what are tiny (<2k) files).
This seems like an issue that needs work before we can consider reading .gz files.
What would be rather neat is to augment the existing plain alphabetical list of software packages with icons denoting the licenses. This would allow the user to get a quick visual summary without necessarily having to click on each and every package to see what their particular licences are.
If implemented, it would make sense to generate a map of "package => licenses" at livecd-rootfs build-time. This should be
Bonus points to allow the list to be sorted by licence type :-)
| Sebastien Bacher (seb128) wrote | #1 |
| Changed in ubuntu-system-settings (Ubuntu): | |
| importance: | Undecided → Wishlist |
| status: | New → Triaged |
| James Hunt (jamesodhunt) wrote | #2 |
| Oliver Grawert (ogra) wrote | #3 |
| Mathieu Trudel-Lapierre (cyphermox) wrote | #4 |
| Changed in livecd-rootfs (Ubuntu): | |
| status: | New → Triaged |
| importance: | Undecided → Wishlist |
Thanks, note that the "sorted by license type" would be another request and shouldn't be listed there. It's also something we look at early but dismissed (at least in the first versions) because it would require to open and parse all the files to be able to build the list, which was taking over a minute of busy cpu or some clever cache/db of those informations (which is doable, but non trivial work and not essential for a v1)