Opened 15 years ago
Closed 13 years ago
#543 closed enhancement (fixed)
Reduce the footprint of the image
Reported by: | wildintellect | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | OSGeoLive | Keywords: | 5.0 |
Cc: |
Description
Hamish has indicated that a target of 3.2GB image may work better for usb sticks of 4 GB, partly to leave adequate space for users to save their own data. Calculating a 2x compression factor that means we would need to trim 500-600 MB from the current virtual machine to reach that goal. I think targeting 4.0 release for this feature would be good. This may coincide with simplification of the example datasets into one common pool and reducing size of some samples like the postgres medford database.
Change History (6)
comment:1 by , 15 years ago
comment:3 by , 14 years ago
new rev of the pgrouting install just now... it seems to bring in an entire QT4 setup.. a lot of packages.. is there already a QT? is this good ?
comment:4 by , 14 years ago
postgresql-8.4-pgrouting-dd (an extra package that adds "driving distance" support to pgRouting) has libcgal-dev as dependency, which has plenty of other dependencies, also QT4.
I will try to find out if libcgal-dev is really necessary and for now remove the postgresql-8.4-pgrouting-dd package from the install script.
comment:5 by , 13 years ago
Keywords: | 5.0 added; 4.0 removed |
---|
I've just added this to build_iso.sh:
# save space on ISO by removing the .svn/ dirs for DIR in `find /usr/local/share/gisvm | grep '\.svn$'` ; do rm -rf "$DIR" done
in the VM it saves 86mb (mostly dupes of incompressible screenshots), but on the ISO it may actually not save anything at all due to the fslint hardlinking of duplicate files.
So I don't know if it will work, but as we are desperate for space it is worth a shot...
Hamish
comment:6 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Alex has confirmed that we have sufficient space for a 4 GIG USB and DVD in 5.0rc6.
see #467 and the
dpkg --get-selections
manifest in the build logs dir. there is lots of low hanging fruit.I'll work on a script to rank installed .deb packages by installed-size, beyond what is now in the top 50 biggest list already found in the main build_log report. but maybe it is better to rank them by compressed size? That list doesn't cover test data, downloaded java packages, etc., though.
df -sh /usr/local/share/*
fyi the main log
df
based size ranking is a rather poor indicator as it includes /tmp/ and eg the first of qgis or grass to install will get hit with the bill for many common deps. It is more useful to quickly see if something went wrong.try this:
Hamish