Have you try removing stuff in /usr/{local/}share/{doc,locale,gtk-doc} ?
You can also remove info and manpage if you don't need them.
On Apr 28, 2013 9:45 PM, "elham abbaszade" <[email protected]> wrote:> Hi > I have storage size constraint. > my disk is 512M > I don't want to reduce LFS. I want to my target machine contain X + Window > manager, Firefox, FreeRDP. > I happily could install all and my target BLFS was created successfully. > but now have 2 problem. one of them is size. > I could reduce the size to 704M but it is large yet. > these are some info about my packages and directory size. > please guide me how to reduce them . > thanks a lot > > du: cannot access './proc/1660/task/1660/fdinfo/3': No such file or > directory > du: cannot access './proc/1660/fd/3': No such file or directory > du: cannot access './proc/1660/fdinfo/3': No such file or directory > 0M ./proc > 1M ./mnt > 4M ./etc > 4M ./sbin > 12M ./lib > 28M ./home > 1M ./opt > 0M ./sys > 1M ./lost+found > 1M ./srv > 4M ./bin > 1M ./run > 637M ./usr > 11M ./boot > 5M ./var > 1M ./tmp > 704M . > 704M total > root [ / ]# cd /usr/ > root [ /usr ]# du -chBM --max-depth=1 > 148M ./share > 1M ./src > 5M ./local > 1M ./etc > 4M ./sbin > 421M ./lib > 61M ./bin > 637M . > 637M total > root [ /usr/share ]# cd share/ > root [ /usr/share ]# du -chBM --max-depth=1 > 1M ./dbus-1 > 1M ./et > 1M ./xcb > 1M ./icons > 1M ./ss > 5M ./misc > 1M ./alsa > 1M ./vala > 1M ./themes > 20M ./vim > 1M ./polkit-1 > 1M ./xml > 1M ./ppd > 1M ./pixmaps > 1M ./fontconfig > 1M ./intltool > 1M ./pulseaudio > 1M ./bash-completion > 1M ./readline > 1M ./gtk-engines > 2M ./locale > 1M ./kde4 > 62M ./fonts > 1M ./bison > 1M ./gcc-4.6.2 > 7M ./idl > 1M ./gtk-2.0 > 6M ./vala-0.18 > 1M ./dtds > 1M ./pkgconfig > 1M ./lxappearance > 1M ./applications > 1M ./grub > 1M ./icon-naming-utils > 1M ./getopt > 1M ./util-macros > 1M ./Eterm > 1M ./color > 1M ./fluxbox > 1M ./tabset > 23M ./gir-1.0 > 1M ./ffmpeg > 1M ./awk > 1M ./imlib2 > 1M ./icu > 1M ./gdb > 1M ./freerdp > 2M ./terminfo > 1M ./colord > 1M ./glib-2.0 > 6M ./X11 > 1M ./gobject-introspection-1.0 > 8M ./cups > 5M ./gettext > 148M . > 148M total > root [ /usr/share ]# cd ../lib/ > root [ /usr/lib ]# du -chBM --max-depth=1 > 1M ./colord-plugins > 1M ./coreutils > 1M ./dbus-1.0 > 1M ./alsa-lib > 1M ./polkit-1 > 1M ./libxslt-plugins > 2M ./gobject-introspection > 3M ./xorg > 17M ./mozilla > 73M ./gbm > 1M ./cairo > 3M ./girepository-1.0 > 1M ./ConsoleKit > 1M ./kde4 > 1M ./gdk-pixbuf-2.0 > 1M ./engines > 1M ./tc > 2M ./gtk-2.0 > 100M ./dri > 1M ./vala-0.18 > 2M ./pkgconfig > 1M ./glibc > 1M ./ldscripts > 2M ./grub > 1M ./icon-naming-utils > 1M ./findutils > 4M ./firefox-16.0.1 > 3M ./pulse > 1M ./audit > 1M ./sudo > 1M ./awk > 1M ./imlib2 > 1M ./icu > 1M ./groff > 1M ./freerdp > 32M ./xulrunner-16.0.1 > 1M ./colord-sensors > 1M ./colord > 1M ./at-spi2-core > 1M ./gnome-settings-daemon-3.0 > 1M ./glib-2.0 > 28M ./xulrunner-devel-16.0.1 > 1M ./X11 > 1M ./pango > 2M ./cups > 1M ./gdbus-2.0 > 1M ./gettext > 1M ./gio > 19M ./egl > 421M . > 421M total > root [ /usr/lib ]# > > > On Mon, Apr 29, 2013 at 4:58 AM, Ken Moffat <[email protected]>wrote: > >> On Sun, Apr 28, 2013 at 08:17:48PM +0100, Matt Burgess wrote: >> > On Sun, 2013-04-28 at 14:10 -0500, Bruce Dubbs wrote: >> > >> > > You don't say why you want to reduce the size. There are many places >> in >> > > /usr/share that can be removed to reduce overall size. You also don't >> > > need every package. If you are not going to build packages on the >> > > target machine, you don't need gcc, auto*, etc. >> > >> > Well, you don't *need* auto{conf,make} even if building packages on the >> > target machine, of course :-) I still think that auto* and potentially >> > libtool too, should be punted over to BLFS, but that's largely because >> > of their horrendously long testsuite times. >> >> If testsuite time was the critical decider, gcc-4.8 should be moved >> to BLFS ;-) >> >> > Well-behaved/correctly >> > packaged projects should have no need for those packages to be >> > installed. >> > >> Yeah, because all packages are well maintained by people who use >> up to date linux systems (by definition, RH and debian-stable don't >> count, let alone those packages whose developers use a BSD system) >> and never have a current release which needs to be fixed for the >> toolchain versions in LFS, nor for any other reason. >> >> I take the opposite view - the need to fix packages using patches >> which require autotools to be invoked is so frequent that they need >> to be in LFS - unless there are the resources to produce, and >> maintain, a version of BLFS tied to a specific LFS version. >> >> ĸen >> -- >> das eine Mal als Tragödie, das andere Mal als Farce >> -- >> http://linuxfromscratch.org/mailman/listinfo/blfs-support >> FAQ: http://www.linuxfromscratch.org/blfs/faq.html >> Unsubscribe: See the above information page >> > > > -- > http://linuxfromscratch.org/mailman/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page >
-- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
