trimming down Fedora installed size

[Marius A]

Hi there,

I've been struggling keeping a fedora 20 install on a "small" SSD, with 6gb
/ partition (/home is separate).

Besides removing packages, I also found this useful:

1. remove /usr/share/docs
2. remove /usr/share/locale/* (all except en and en_US)
3. cleanup /var/log/journal, which seems it's not automatically rotated

While this saves space, it also results in package upgrade warnings due to
missing files.

Are there any other disk space saving tips?

What do you think about excluding docs by default in Fedora packages?
And for docs either go online, or have a command to install/sync docs for
all installed packages? (similar to ruby or npm packages install, not using
rpm packages)

I think less than 0.1% of users ever look into /usr/share/doc, but I don't
have any data to back this up.
As more folks switch to SSDs, it would benefit both for disk space saving
and wearing to have less space occupied by default.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140409/cfb5c346/attachment.html>

[Ville Skyttä]

Post by Marius A
1. remove /usr/share/docs

Try this in /etc/rpm/macros.whatever:
%_excludedocs 1

But that'll exclude _all_ files marked as docs in packages such as man
pages, it's not limited to /usr/share/doc. You might also/instead want
to try this:
%_netsharedpath %{_datadir}/doc

Post by Marius A
2. remove /usr/share/locale/* (all except en and en_US)

Try this in /etc/rpm/macros.whatever:
%_install_langs en

It's possible that these settings break some things such as scriptlets
that do not take missing files into account, but at least they're
cleaner attempts than simply deleting installed files/dirs.

[James Antill]

Post by Ville Skyttä

Post by Marius A
1. remove /usr/share/docs

%_excludedocs 1

For recent yum it's significantly better to do:

yum fs filter nodocs

Post by Ville Skyttä
%_install_langs en

Dito. to get rid of extra languages by:

yum fs filter langs en

...then you can yum fs refilter / yum fs refilter-cleanup.

Post by Ville Skyttä
It's possible that these settings break some things such as scriptlets
that do not take missing files into account, but at least they're
cleaner attempts than simply deleting installed files/dirs.

This can still be true though.

[Matthew Miller]

Post by James Antill
yum fs filter nodocs
yum fs filter langs en
...then you can yum fs refilter / yum fs refilter-cleanup.

So -- if the host is originally installed with anaconda's kickstart options
for nodocs and language selection, will `yum fs refilter` still work?

[James Antill]

Post by Matthew Miller

Post by James Antill
yum fs filter nodocs
yum fs filter langs en
...then you can yum fs refilter / yum fs refilter-cleanup.

So -- if the host is originally installed with anaconda's kickstart options
for nodocs and language selection, will `yum fs refilter` still work?

The way the nodocs stuff is done in anaconda is by changing the rpm
macros directly where yum uses the slightly saner API there of setting
the rpm.RPMTRANS_FLAG_NODOCS transaction flag. And yum looks just for
that transaction flag when it sets/gets the yumdb tsflag_nodocs.
On the other hand, the only way to change the installed languages is
via. the rpm macro ... so while anaconda doesn't use the yum
configuration to do it, I believe yum will still see that the rpm macro
has changes and get/set yumdb ts_install_langs correctly.

[Marius A]

Post by James Antill

Post by Ville Skyttä

Post by Marius A
1. remove /usr/share/docs

%_excludedocs 1

yum fs filter nodocs

Post by Ville Skyttä
%_install_langs en

yum fs filter langs en
...then you can yum fs refilter / yum fs refilter-cleanup.

Wow, this is exactly what I was looking for. Thanks!
On Fedora 21, any way to apply these before installing to SDD from live usb
image? e.g. open terminal, run fs filter's, then start the install?

This thread has spawned good discussions tough :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140410/16fe195f/attachment-0001.html>

[James Antill]

Post by Marius A
Wow, this is exactly what I was looking for. Thanks!
On Fedora 21, any way to apply these before installing to SDD from live usb
image? e.g. open terminal, run fs filter's, then start the install?

So the way "yum fs filter" works is to change the yum configuration for
tsflags and override_install_langs.
If you specify --installroot when running the filter command then yum
should write the new yum.conf within the installroot. Then when you run
the next installroot command, to actually install, it will pickup those
configurations and dtrt.
You can also use --setopt to set them too, or .conf.blah if you are
using the API.

[Adam Williamson]

Post by James Antill

Post by Marius A
Wow, this is exactly what I was looking for. Thanks!
On Fedora 21, any way to apply these before installing to SDD from live usb
image? e.g. open terminal, run fs filter's, then start the install?

So the way "yum fs filter" works is to change the yum configuration for
tsflags and override_install_langs.
If you specify --installroot when running the filter command then yum
should write the new yum.conf within the installroot. Then when you run
the next installroot command, to actually install, it will pickup those
configurations and dtrt.
You can also use --setopt to set them too, or .conf.blah if you are
using the API.

(adamw-catching-up-on-devel-thread-necro-alert!)

but that would not be any use to a live install, because a live install
doesn't actually do any package transactions, would it?

[James Antill]

Post by Adam Williamson

Post by James Antill

Post by Marius A
Wow, this is exactly what I was looking for. Thanks!
On Fedora 21, any way to apply these before installing to SDD from live usb
image? e.g. open terminal, run fs filter's, then start the install?

So the way "yum fs filter" works is to change the yum configuration for
tsflags and override_install_langs.
If you specify --installroot when running the filter command then yum
should write the new yum.conf within the installroot. Then when you run
the next installroot command, to actually install, it will pickup those
configurations and dtrt.
You can also use --setopt to set them too, or .conf.blah if you are
using the API.

(adamw-catching-up-on-devel-thread-necro-alert!)

Cast of raise the dead succeeded! <Badge unlocked>

Post by Adam Williamson
but that would not be any use to a live install, because a live install
doesn't actually do any package transactions, would it?

There aren't any rpmdb transactions to do the copy ... but AIUI you can
still do them, right?

There are also two parts to the filtering in yum:

yum fs filter documentation

...this tells yum to start filtering all the documentation from all
future transactions, but because of the way that this applies to removes
as well as installs in rpm[1] yum also has:

yum fs refilter
yum fs refilter-cleanup

...the former alters all the yumdb.ts_install_langs and
yumdb.tsflag_nodocs flags for the installed packages (without having to
do an action reinstall), so that those packages are marked as having
their docs/langs filtered (by yumdb, rpm -V will still complain).
The later then deletes all the files that are on disk but should be
filtered.


[1] So if you do an upgrade the documentation for the new package is
filtered from being installed, but the documentation from the old
package is also filtered from being removed.

[James Antill]

Post by James Antill
yum fs refilter
...the former alters all the yumdb.ts_install_langs and
yumdb.tsflag_nodocs flags for the installed packages (without having to
do an actual reinstall), so that those packages are marked as having
their docs/langs filtered (by yumdb, rpm -V will still complain).

I apparently changed/fixed this at some point from when I remembered,
so it does do the reinstall transaction (and thus. rpm -V is happy). But
I believe this is fine on the live CD, right? (you can run transactions
to install/reinstall packages)?

[J. Randall Owens]

Post by James Antill

Post by Ville Skyttä

Post by Marius A
1. remove /usr/share/docs

%_excludedocs 1

yum fs filter nodocs

Post by Ville Skyttä
%_install_langs en

yum fs filter langs en
...then you can yum fs refilter / yum fs refilter-cleanup.

Post by Ville Skyttä
It's possible that these settings break some things such as scriptlets
that do not take missing files into account, but at least they're
cleaner attempts than simply deleting installed files/dirs.

This can still be true though.

Of course, this would all be much more obvious if the `yum help` output
didn't say "fs Creates filesystem snapshots, or lists/deletes current
snapshots," exactly what it also says for fssnapshot. Bug filed. [1]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1086461

[Michal Schmidt]

Post by Marius A
3. cleanup /var/log/journal, which seems it's not automatically rotated

It's supposed to be automatic. How big did it become on your system?
If the default size limits do not suit you, you can change them in
/etc/systemd/journald.conf.

Michal

[&quot;Jóhann B. Guðmundsson&quot;]

Post by Marius A
Are there any other disk space saving tips?

Users should not have to result doing disk saving tips.

I would say in the long run we should be working towards creating
separated locale,doc,man packages

JBG

[Stephen Gallagher]

Post by &quot;Jóhann B. Guðmundsson&quot;

Post by Marius A
Are there any other disk space saving tips?

Users should not have to result doing disk saving tips.
I would say in the long run we should be working towards creating
separated locale,doc,man packages

Hmm, I wonder if RPM 4.12 would allow us to do this with weak
dependencies?

Perhaps something like having a metapackage on the system for docs and
one for each language. Then we could break up the doc and language
packages into sub-packages that are installed conditionally on the
presence of that metapackage on the system.

Of course, I think there would still be work needed in RPM to support
adding a language later, but maybe we could solve that with special
tooling or a yum plugin.

[&quot;Jóhann B. Guðmundsson&quot;]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by &quot;Jóhann B. Guðmundsson&quot;

Post by Marius A
Are there any other disk space saving tips?

Users should not have to result doing disk saving tips.
I would say in the long run we should be working towards creating
separated locale,doc,man packages

Hmm, I wonder if RPM 4.12 would allow us to do this with weak
dependencies?
Perhaps something like having a metapackage on the system for docs and
one for each language. Then we could break up the doc and language
packages into sub-packages that are installed conditionally on the
presence of that metapackage on the system.
Of course, I think there would still be work needed in RPM to support
adding a language later, but maybe we could solve that with special
tooling or a yum plugin.

Yeah and we probably have to move the man packages in their own
sub-package once the rpm trigger that replaces the cron job lands

JBG

[Matthew Miller]

Post by Stephen Gallagher

Post by &quot;Jóhann B. Guðmundsson&quot;
I would say in the long run we should be working towards creating
separated locale,doc,man packages

Hmm, I wonder if RPM 4.12 would allow us to do this with weak
dependencies?
Perhaps something like having a metapackage on the system for docs and
one for each language. Then we could break up the doc and language
packages into sub-packages that are installed conditionally on the
presence of that metapackage on the system.
Of course, I think there would still be work needed in RPM to support
adding a language later, but maybe we could solve that with special
tooling or a yum plugin.

+1 to all of this. Needs:

* rpm macros, possibly other RPM work
* packaging guidelines
* yum/dnf tooling
* a plan for realistically getting from where we are now to where we
want to be
* executing on that plan

Cloud SIG has a lot of interest in this and we may be able to find some
contributors to the effort there.

https://fedoraproject.org/wiki/Changes/Use_license_macro_in_RPMs_for_packages_in_Cloud_Image

could be a model (and is in fact a prerequisite).

[Matthias Clasen]

Post by Matthew Miller

Post by Stephen Gallagher

Post by &quot;Jóhann B. Guðmundsson&quot;
I would say in the long run we should be working towards creating
separated locale,doc,man packages

Hmm, I wonder if RPM 4.12 would allow us to do this with weak
dependencies?
Perhaps something like having a metapackage on the system for docs and
one for each language. Then we could break up the doc and language
packages into sub-packages that are installed conditionally on the
presence of that metapackage on the system.
Of course, I think there would still be work needed in RPM to support
adding a language later, but maybe we could solve that with special
tooling or a yum plugin.

* rpm macros, possibly other RPM work
* packaging guidelines
* yum/dnf tooling
* a plan for realistically getting from where we are now to where we
want to be
* executing on that plan
From the desktop/workstation perspective, here are a few things I would

like to see if we decide to work on this:

Support for a new locale is more or less like a 'system extension' for
the OS. It would be good to define clear rules for what it means to
provide a subpackage that becomes part of this system extension.

In an ideal world, this could even be automatic and pattern-based (e.g.
if you install anything into /usr/lib64/gstreamer-1.0, you are providing
a 'codec' extension, and all the files below that directory belong to
it).

To present this in the UI, we need to know the available 'extension
points' (either a fixed list, or a way to enumerate them), as well as
the installed and available extensions for each, including suitable
metadata (name+short description at least).

[Florian Festi]

Post by Matthew Miller
From the desktop/workstation perspective, here are a few things I would
Support for a new locale is more or less like a 'system extension' for
the OS. It would be good to define clear rules for what it means to
provide a subpackage that becomes part of this system extension.

Yes, but my guess this is not very complicated. Natural languages are
pretty straight forward. All other 'system extension' will basically
come with their own description. We just have to make sure that the
description as shown to the user is not completely ignored by the
packages using it.

Post by Matthew Miller
In an ideal world, this could even be automatic and pattern-based (e.g.
if you install anything into /usr/lib64/gstreamer-1.0, you are providing
a 'codec' extension, and all the files below that directory belong to
it).

*cough* *cough*

Post by Matthew Miller
To present this in the UI, we need to know the available 'extension
points' (either a fixed list, or a way to enumerate them), as well as
the installed and available extensions for each, including suitable
metadata (name+short description at least).

We need the rethink the whole packaging UI anyway. Comps still has all
its known problems. SoftwareCenter has its own, very special view on the
packages, and no one has a clue how to make use of the weak weak
dependencies (which are not completely unlike optional packages in comps).

So making the number of installed and available packages more manageable
is one of the next big things that need to be done after the basic
infrastructure is in place.

Florian

[Florian Festi]

Post by Stephen Gallagher

Post by &quot;Jóhann B. Guðmundsson&quot;

Post by Marius A
Are there any other disk space saving tips?

Users should not have to result doing disk saving tips.
I would say in the long run we should be working towards creating
separated locale,doc,man packages

Hmm, I wonder if RPM 4.12 would allow us to do this with weak
dependencies?
Perhaps something like having a metapackage on the system for docs and
one for each language. Then we could break up the doc and language
packages into sub-packages that are installed conditionally on the
presence of that metapackage on the system.
Of course, I think there would still be work needed in RPM to support
adding a language later, but maybe we could solve that with special
tooling or a yum plugin.

Yes, this is one of the reasons we go for more expressive relations in
RPM. You already very closely describe what I have in mind.

There are basically two possible ways of making the distribution more
flexible in the future:

1) Normal weak dependencies. In a normal install all the docs (and all
other bells and whistles) get installed by default. You can
remove/deselect packages which are pulled in by weak dependencies. You
can even switch off all weak dependencies to only get the core packages.

2) Rich dependencies. Doc and language packages can be build as
"bridging" packages that are only installed if two other packages are
present. This can be done by adding e.g.

Recommends: foo-langpack-hu if langsupport-hu

to package foo or

Supplements: foo and langsupport-hu

to the foo-langpack-hu package. Similar things can be done for docs or
any other set of packages that should be controlled by a single "switch"
package.

The nice thing about this is that no additional tooling is needed.
Installing foo will automatically install the lang packs for all
installed languages and installing a new langsupport package will
install the langpacks for all installed packages.

The plan is to get all pieces for 1) into F21. So it could already be
used for F22. I will try to get 2) ready in this time frame, too, but
the bets are still open.

Florian

[Stephen Gallagher]

Post by Florian Festi

Post by Stephen Gallagher

Post by &quot;Jóhann B. Guðmundsson&quot;

Post by Marius A
Are there any other disk space saving tips?

Users should not have to result doing disk saving tips.
I would say in the long run we should be working towards
creating separated locale,doc,man packages

Hmm, I wonder if RPM 4.12 would allow us to do this with weak
dependencies?
Perhaps something like having a metapackage on the system for
docs and one for each language. Then we could break up the doc
and language packages into sub-packages that are installed
conditionally on the presence of that metapackage on the system.
Of course, I think there would still be work needed in RPM to
support adding a language later, but maybe we could solve that
with special tooling or a yum plugin.

Yes, this is one of the reasons we go for more expressive relations
in RPM. You already very closely describe what I have in mind.
There are basically two possible ways of making the distribution
1) Normal weak dependencies. In a normal install all the docs (and
all other bells and whistles) get installed by default. You can
remove/deselect packages which are pulled in by weak dependencies.
You can even switch off all weak dependencies to only get the core
packages.
2) Rich dependencies. Doc and language packages can be build as
"bridging" packages that are only installed if two other packages
are present. This can be done by adding e.g.
Recommends: foo-langpack-hu if langsupport-hu
to package foo or
Supplements: foo and langsupport-hu

This construct would be extremely valuable to the SSSD as well:

%package -n client
Recommends: sssd-client.i686 if glibc.i686

Post by Florian Festi
to the foo-langpack-hu package. Similar things can be done for docs
or any other set of packages that should be controlled by a single
"switch" package.
The nice thing about this is that no additional tooling is needed.
Installing foo will automatically install the lang packs for all
installed languages and installing a new langsupport package will
install the langpacks for all installed packages.

The second half of this statement is the exciting part to me.

It's pretty easy to install a language at package-install time, but in
order to add the language subpackages for all installed packages on
the system if the new langsupport package comes in will mean
re-processing all of the dependencies on the installed packages.
Probably very slow, but certainly valuable.

Post by Florian Festi
The plan is to get all pieces for 1) into F21. So it could already
be used for F22. I will try to get 2) ready in this time frame,
too, but the bets are still open.

This would be fantastic, now we just need the FPC to agree. Might be
worth filing an FPC bug or two now for them to debate before pushing
too hard here.

[Florian Festi]

Post by Stephen Gallagher
%package -n client
Recommends: sssd-client.i686 if glibc.i686

That's not exactly by accident...

Post by Stephen Gallagher
It's pretty easy to install a language at package-install time, but in
order to add the language subpackages for all installed packages on
the system if the new langsupport package comes in will mean
re-processing all of the dependencies on the installed packages.
Probably very slow, but certainly valuable.

Well, there is a reason why Fedora is moving to a new dependency solver.
I am pretty optimistic about performance.

Post by Stephen Gallagher

Post by Florian Festi
The plan is to get all pieces for 1) into F21. So it could already
be used for F22. I will try to get 2) ready in this time frame,
too, but the bets are still open.

This would be fantastic, now we just need the FPC to agree. Might be
worth filing an FPC bug or two now for them to debate before pushing
too hard here.

For now there is just https://fedoraproject.org/wiki/Changes/RPM-4.12

I will talk to the FPC as soon as the parts are all in place. Be aware
that it is not enough to just implement the stuff. It needs to be tested
and to make its way to the builders. Even with a hurry things need quite
some time in RPM land.

Florian

[Bill Nottingham]

Post by Florian Festi
1) Normal weak dependencies. In a normal install all the docs (and all
other bells and whistles) get installed by default. You can
remove/deselect packages which are pulled in by weak dependencies. You
can even switch off all weak dependencies to only get the core packages.
2) Rich dependencies. Doc and language packages can be build as
"bridging" packages that are only installed if two other packages are
present. This can be done by adding e.g.
Recommends: foo-langpack-hu if langsupport-hu
to package foo or
Supplements: foo and langsupport-hu
to the foo-langpack-hu package. Similar things can be done for docs or
any other set of packages that should be controlled by a single "switch"
package.

Given the number of packages that ship localization, this seems like it
would have a pretty dramatic effect on metadata size. Is this a concern?

Bill

[Florian Festi]

Post by Bill Nottingham
Given the number of packages that ship localization, this seems like it
would have a pretty dramatic effect on metadata size. Is this a concern?

Meta data is a concern. But the major part of the meta data is file data
and change logs. Everything else is less than 10%. So doubling or even
tripling this part won't hurt.

The actual issue we have with meta data is that is is downloaded over
and over again (for updates). Should we ever get this fixed the growth
of meta data is no longer an issue.

Florian

[James Antill]

Post by Florian Festi

Post by Bill Nottingham
Given the number of packages that ship localization, this seems like it
would have a pretty dramatic effect on metadata size. Is this a concern?

Meta data is a concern. But the major part of the meta data is file data
and change logs. Everything else is less than 10%. So doubling or even
tripling this part won't hurt.

I'm not sure what you mean by 10% here, but tripling primary would hurt
a lot. Eg. for Fedora 18/updates we have:

404K comps-f18.xml.gz
17M filelists.sqlite.bz2
6.2M other.sqlite.bz2
780K pkgtags.sqlite.gz
2.7M prestodelta.xml.gz
12M primary.sqlite.bz2
1.2M updateinfo.xml.gz

...and downloading ~15M does matter, so while compression helps and we
are already in a lot of pain ... more pain is more pain. Also this
locally turns into:

86M filelists_db.sqlite
34M other_db.sqlite
1.8M pkgtags.sqlite
13M prestodelta.xml
51M primary_db.sqlite
13M updateinfo.xml

...and randomly using 80+MB of extra disk space is also painful in some
use cases.

Not that I assume splitting lanauges and docs. into sub packages would
triple primary numbers, but if it did ... that would be bad.

[Bill Nottingham]

Post by James Antill
Not that I assume splitting lanauges and docs. into sub packages would
triple primary numbers, but if it did ... that would be bad.

To put it in perspective, if we split out 'langpacks' for apps per language,
something like gedit then grows *100* new subpackages.

Bill

[Andrew Price]

Post by Bill Nottingham

Post by James Antill
Not that I assume splitting lanauges and docs. into sub packages would
triple primary numbers, but if it did ... that would be bad.

To put it in perspective, if we split out 'langpacks' for apps per language,
something like gedit then grows *100* new subpackages.
Bill

It's a shame we can't store .mo files compressed. The ratio seems quite
good:

[root at phanto ~]# cd /usr/share
[root at phanto share]# cp -r locale locale-compressed
[root at phanto share]# find locale-compressed -type f -name '*.mo' -exec
bzip2 --best {} \;
[root at phanto share]# du -sh locale locale-compressed
657M locale
245M locale-compressed

(NB this isn't a newly installed system.)

Andy

[Richard W.M. Jones]

Post by Andrew Price

Post by Bill Nottingham

Post by James Antill
Not that I assume splitting lanauges and docs. into sub packages would
triple primary numbers, but if it did ... that would be bad.

To put it in perspective, if we split out 'langpacks' for apps per language,
something like gedit then grows *100* new subpackages.
Bill

It's a shame we can't store .mo files compressed.

Unfortunately .mo files are mmapped and shared between processes, so
compressing them wouldn't work :-(

Rich.

[Andrew Price]

Post by Richard W.M. Jones

Post by Andrew Price

Post by Bill Nottingham

Post by James Antill
Not that I assume splitting lanauges and docs. into sub packages would
triple primary numbers, but if it did ... that would be bad.

To put it in perspective, if we split out 'langpacks' for apps per language,
something like gedit then grows *100* new subpackages.
Bill

It's a shame we can't store .mo files compressed.

Unfortunately .mo files are mmapped and shared between processes, so
compressing them wouldn't work :-(

That's what I thought :/

Just thinking out loud, but maybe with an updated gettext(3) it could
work, but I guess it would require some hefty changes in libc, right?
Unless programs could be linked against a "zintl" lib to provide an
alternative gettext(3) perhaps. Either way it would need to be
transparently backward compatible with the current .mo format and
obviously there'd be performance concerns for some programs so they'd
need to stick with the current implementation. Portability shouldn't be
an issue though as .po files can be compiled to whatever .mo format the
distro/package uses. I think there's potential for innovation in that
area anyway, but it would need some momentum behind it.

Andy

[James Antill]

Post by Bill Nottingham

Post by James Antill
Not that I assume splitting lanauges and docs. into sub packages would
triple primary numbers, but if it did ... that would be bad.

To put it in perspective, if we split out 'langpacks' for apps per language,
something like gedit then grows *100* new subpackages.

FWIW here is some data (For x86_64):

Ver | pkgs. num. | pkgs. size | primary size
--------------------------------------------
10 | 14,303 | 16 G | 8.2M
11 | 16,577 | 20 G | 11M
12 | 19,122 | 17 G | 12M
13 | 20,840 | 20 G | 13M
14 | 22,161 | 22 G | 14M
15 | 24,085 | 23 G | 14M
16 | 25,098 | 25 G | 15M
17 | 27,033 | 27 G | 15M
18 | 33,868 | 33 G | 18M
19 | 36,253 | 36 G | 18M
20 | 38,561 | 38 G | 19M

...which gives about 500-600 bytes of primary per. package. Doing the
same thing for updates gives:

Ver | pkgs. num. | pkgs. size | primary size
--------------------------------------------
10 | 9,024 | 11 G | 6M
11 | 10,066 | 13 G | 6.6M
12 | 9,645 | 12 G | 6.4M
13 | 9,655 | 12 G | 6.5M
14 | 9,982 | 13 G | 6.8M
15 | 10,214 | 13 G | 7.1M
16 | 11,055 | 15 G | 7.6M
17 | 13,163 | 18 G | 8.4M
18 | 18,606 | 20 G | 12M

...which is a bit more at about 650 bytes per. package, probably due to
compression not working as well with small numbers of packages.

So to do some math with F20:

"in @^minimal-environment" gives me 218 packages, so adding an extra
docs package to just those is ~120k in release primary MD
"in @^web-server-environment" (which requires filelists to resolve,
nice) is 524 packages so you are at ~300k
"in @^gnome-desktop-environment" is 1,265 packages and you are at
~750k.

...if you added 100x the packages to even the first though, it would
obviously be pretty bad.




Stats. generating using:

repo=fedora

for num in $(seq 10 20); do
yum --disablerepo=\* --enablerepo=$repo repoinfo $repo --releasever=$num | \
egrep -- '-(name|pkg|size)'
( cd /var/cache/yum/x86_64/$num/$repo; ls --size -h *primary* )
done

[Florian Festi]

Post by James Antill
20 | 38,561 | 38 G | 19M

So there are 20MB of meta data that need to be downloaded once. This can
hardly be a problem - even if the size tripled.

Post by James Antill
18 | 18,606 | 20 G | 12M

Ok, let this be another 20MB for the updates during the life time of an
Fedora release. This would also not be an issue if we had not to
download this file over and over again and then inflate it to ten times
it's size.

The main issue here is not the amount of data but the way yum handles it
and the refusal of yum upstream to even consider an efficient meta data
handling by insisting on the reconstruction of transport representation
on the client side.

In the end we need a saner MD handling no matter if we go for finer
grained packages or not. I hope DNF will be able to provide this at some
point when they are done with the more basic things.

Florian

[Peter Oliver]

Post by Florian Festi

Post by Bill Nottingham
Given the number of packages that ship localization, this seems like it
would have a pretty dramatic effect on metadata size. Is this a concern?

Meta data is a concern. But the major part of the meta data is file data
and change logs. Everything else is less than 10%. So doubling or even
tripling this part won't hurt.

What about performance? I don't have any figures, but my feeling was
that TeX seemed to update awfully slowly after it was split into many
small packages.

[Basil Mohamed Gohar]

Post by Peter Oliver

Post by Florian Festi

Post by Bill Nottingham
Given the number of packages that ship localization, this seems like it
would have a pretty dramatic effect on metadata size. Is this a concern?

Meta data is a concern. But the major part of the meta data is file data
and change logs. Everything else is less than 10%. So doubling or even
tripling this part won't hurt.

What about performance? I don't have any figures, but my feeling was
that TeX seemed to update awfully slowly after it was split into many
small packages.

If package metadata is a problem, what if we split up the repositories
and allocate some, that we can deem to be, to some degree, optional, to
be for these less-than-mandatory packages.

So, for example, if the extra languages packages are put into their own
repository. This would, of course, be unfair to the languages that are
not considered main, and this would likely heavily be biased towards
English given it probably has the widest coverage.

But what if manpages were in their own repository?

I guess my point is, can we spread the problem out across semi-optional
repositories and handle dependencies in a soft a way such that they'll
be installed if they are present [i.e., the repository(-ies) with the
given dependency(-ies) is/are present] but then the install continues
without a problem except maybe a gentle notice that there exist optional
dependencies so someone can choose to enable the associated repositories?

I don't know if this will introduce more problems than it solves, but
for the typical 1TB+ desktop user of Fedora, we can enable pretty-much
all of these "optional" repositories, and for the embedded and/or
minimal/micro installs, these optional repositories can be left unenabled.

I think this would require fewer changes to the dependency logic and RPM
itself than, say, a complicated set of flags and package labeling/tagging.

P.S. Please forgive me if I use terms that might have specific meaning
to the packaging team (maybe tagging means something I don't intend in
that context, I'm using it generically).

[Matthew Miller]

Post by Marius A
I've been struggling keeping a fedora 20 install on a "small" SSD, with 6gb
/ partition (/home is separate).

This part of conversation probably belongs on the user list rather than
devel. But there are some development-related aspects (see rest of thread)
and while we're at it, I have some constructive practical points as well.

Post by Marius A
2. remove /usr/share/locale/* (all except en and en_US)

Also do

localedef --delete-from-archive $(localedef --list-archive | grep -v -i ^$LANG | xargs)

mv /usr/lib/locale/locale-archive /usr/lib/locale/locale-archive.tmpl

build-locale-archive

Post by Marius A
3. cleanup /var/log/journal, which seems it's not automatically rotated

It actually _is_ automatically rotated. See /etc/systemd/journald.conf and
`man journald.conf`. Particularly, look at SystemMaxUse, SystemKeepFree, and
MaxRetentionSec.

[Basil Mohamed Gohar]

Post by Marius A
I think less than 0.1% of users ever look into /usr/share/doc, but I
don't have any data to back this up.

I think I must fit into this 0.1% (and I am not disputing that that is
the correct ratio, either) because I definitely use /usr/share/doc, but
mostly because that holds more than just "documentation". For example,
avahi stores example service definitions for ssh and sftp under
/usr/share/doc, and I believe this behavior exists with other packages
for non-strictly-documentation data.

I don't know what the standard is for defining what, if anything, should
be placed under /usr/share/doc, but as it stands now, we should at least
know and acknowledge that it's not just READMEs and HTML files when we
make the decision to not install it by default or to reduce the chance
that it's installed.

Having said that, I am all for saving space on a default install and/or
making a more minimal install possible. I noticed just now that
manpages are compressed, but with gz. I am sure this discussion has
already happened, but maybe we can have an alternative man-xz format
that will reduce the size of the individual packages for a Fedora
Minimal or somesuch (I think manpages should be very, very far down on
the list of what to be left out from an install, as they are sometimes
the last resort on what to do).

My two bits on the idea.

[Matthew Miller]

Post by Basil Mohamed Gohar
I think I must fit into this 0.1% (and I am not disputing that that is
the correct ratio, either) because I definitely use /usr/share/doc, but
mostly because that holds more than just "documentation". For example,
avahi stores example service definitions for ssh and sftp under
/usr/share/doc, and I believe this behavior exists with other packages
for non-strictly-documentation data.

This is a packaging bug and should (probably must) be fixed.

[Stephen Gallagher]

On Wed, Apr 09, 2014 at 09:53:10AM -0400, Basil Mohamed Gohar

Post by Basil Mohamed Gohar
I think I must fit into this 0.1% (and I am not disputing that
that is the correct ratio, either) because I definitely use
/usr/share/doc, but mostly because that holds more than just
"documentation". For example, avahi stores example service
definitions for ssh and sftp under /usr/share/doc, and I believe
this behavior exists with other packages for
non-strictly-documentation data.

This is a packaging bug and should (probably must) be fixed.

Why is this a packaging bug? %doc is allowed to contain anything that
is not used by the package for runtime execution. It's very common
(and appropriate!) to have things like example config files in %doc.

[Matthew Miller]

Post by Stephen Gallagher

Post by Matthew Miller

Post by Basil Mohamed Gohar
I think I must fit into this 0.1% (and I am not disputing that
that is the correct ratio, either) because I definitely use
/usr/share/doc, but mostly because that holds more than just
"documentation". For example, avahi stores example service
definitions for ssh and sftp under /usr/share/doc, and I believe
this behavior exists with other packages for
non-strictly-documentation data.

This is a packaging bug and should (probably must) be fixed.

Why is this a packaging bug? %doc is allowed to contain anything that
is not used by the package for runtime execution. It's very common
(and appropriate!) to have things like example config files in %doc.

Sorry, I missed the word "example". Examples _are_ "just documentation",
pretty much by definition, and shouldn't be required at runtime. So I'm not
seeing a problem here.

[Ralf Corsepius]

Post by Matthew Miller

Post by Basil Mohamed Gohar
I think I must fit into this 0.1% (and I am not disputing that that is
the correct ratio, either) because I definitely use /usr/share/doc, but
mostly because that holds more than just "documentation". For example,
avahi stores example service definitions for ssh and sftp under
/usr/share/doc, and I believe this behavior exists with other packages
for non-strictly-documentation data.

This is a packaging bug and should (probably must) be fixed.

Pardon, but you're not right: Examples are considered to be documentation.

Ralf

[Ralf Corsepius]

Post by Basil Mohamed Gohar
Having said that, I am all for saving space on a default install and/or
making a more minimal install possible. I noticed just now that
manpages are compressed, but with gz. I am sure this discussion has
already happened, but maybe we can have an alternative man-xz format
that will reduce the size of the individual packages for a Fedora
Minimal or somesuch (I think manpages should be very, very far down on
the list of what to be left out from an install, as they are sometimes
the last resort on what to do).

SUSE once (> 10 years ago) had used *.bz2-compressed manpages, but for a
while they also have returned to *.gz.

I don't know why they did so, but I'd guess it simply doesn't pay-off
size-wise and introduced too much of a penalty speed-wise.

So, I'd question the usefulness of not installing man-pages, because
their sizes are comparatively small on today's disk-scales, e.g. on my
primary system:
# du -sh /usr/share/man
89M /usr/share/man

That's almost neglibile in comparision to the overall size of the
installation.

Ralf

[&quot;Jóhann B. Guðmundsson&quot;]

Post by Ralf Corsepius
So, I'd question the usefulness of not installing man-page

It's more about getting to the point of being able to remove them and or
have the option not to install them.

Whether they should or should not be installed by default depends on
people personal preferences and SIG's uses cases/target audience

Embedded + cloud + containers probably want to remove them

Server + desktop probably wants to keep them

And to you 89m is little, to me it's much so fourth and so on...

JBG

[Corey Sheldon]

may be easier to just rewrite the mandb for it rather than create extra
confusion of two man pages


Corey W Sheldon
Owner, 1st Class Mobile Shine
310.909.7672
www.facebook.com/1stclassmobileshine


On Wed, Apr 9, 2014 at 10:49 AM, "Jóhann B. Guðmundsson" <johannbg at gmail.com

Post by &quot;Jóhann B. Guðmundsson&quot;

Post by Ralf Corsepius
So, I'd question the usefulness of not installing man-page

It's more about getting to the point of being able to remove them and or
have the option not to install them.
Whether they should or should not be installed by default depends on
people personal preferences and SIG's uses cases/target audience
Embedded + cloud + containers probably want to remove them
Server + desktop probably wants to keep them
And to you 89m is little, to me it's much so fourth and so on...
JBG
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140409/bdfcebd3/attachment.html>

[Martin Langhoff]

On Wed, Apr 9, 2014 at 10:49 AM, "Jóhann B. Guðmundsson"

Post by &quot;Jóhann B. Guðmundsson&quot;
It's more about getting to the point of being able to remove them and or
have the option not to install them.

See my other email on this thread. Following on what I wrote there,
instead of reworking all the packages across the distro, a script can
be written to achieve the equivalent of exclude_docs.

Post by &quot;Jóhann B. Guðmundsson&quot;
Embedded + cloud + containers probably want to remove them

Those already work right with exclude_docs -- I have been a primary
user of both use cases (OLPC as embedded, cloud/containers now).

cheers,



m

[Alexey I. Froloff]

Post by &quot;Jóhann B. Guðmundsson&quot;

Post by Ralf Corsepius
So, I'd question the usefulness of not installing man-page

It's more about getting to the point of being able to remove them and
or have the option not to install them.

Since man pages are marked as %doc, you can use %_excludedocs
macro:

$ grep -B2 excludedoc /usr/lib/rpm/macros
# Boolean (i.e. 1 == "yes", 0 == "no") that controls whether files
# marked as %doc should be installed.
#%_excludedocs

And also:

$ grep -B3 install_langs /usr/lib/rpm/macros
# A colon separated list of desired locales to be installed;
# "all" means install all locale specific files.
#
%_install_langs all
--
Regards, --
Sir Raorn. --- https://plus.google.com/+AlexeyFroloff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140409/0909793d/attachment.sig>

[&quot;Jóhann B. Guðmundsson&quot;]

Post by Alexey I. Froloff

Post by &quot;Jóhann B. Guðmundsson&quot;

Post by Ralf Corsepius
So, I'd question the usefulness of not installing man-page

It's more about getting to the point of being able to remove them and
or have the option not to install them.

Since man pages are marked as %doc, you can use %_excludedocs
$ grep -B2 excludedoc /usr/lib/rpm/macros
# Boolean (i.e. 1 == "yes", 0 == "no") that controls whether files
# marked as %doc should be installed.
#%_excludedocs
$ grep -B3 install_langs /usr/lib/rpm/macros
# A colon separated list of desired locales to be installed;
# "all" means install all locale specific files.
#
%_install_langs all

Does not solve the problem of dependency like for example if we want to
get rid of man-db and it's dependency's so forth and so on.

The only way we can move forward is *fixing* our dependency tree. It is
a mess to say the least

JBG

[Alexey I. Froloff]

Post by &quot;Jóhann B. Guðmundsson&quot;
Does not solve the problem of dependency like for example if we want
to get rid of man-db and it's dependency's so forth and so on.

Well, it does solve the wasted disk space problem.

Post by &quot;Jóhann B. Guðmundsson&quot;
The only way we can move forward is *fixing* our dependency tree. It
is a mess to say the least

I second that...
--
Regards, --
Sir Raorn. --- https://plus.google.com/+AlexeyFroloff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140409/e3b78fc4/attachment.sig>

[Ralf Corsepius]

Post by &quot;Jóhann B. Guðmundsson&quot;

Post by Ralf Corsepius
So, I'd question the usefulness of not installing man-page

It's more about getting to the point of being able to remove them and or
have the option not to install them.

Well, rpm-wise, all files marked %doc are considered to be optional.

I.e. rm -rf /usr/share/doc/* etc. are supposed to work
=> rpm issuing warnings/errors after %doc-files removals should be
considered to be packaging bugs (I don't have a case at hand, but know
there are such bugs).

Post by &quot;Jóhann B. Guðmundsson&quot;
Whether they should or should not be installed by default depends on
people personal preferences and SIG's uses cases/target audience
Embedded + cloud + containers probably want to remove them
Server + desktop probably wants to keep them
And to you 89m is little, to me it's much so fourth and so on...

C'mon, we have packages whose install-sizes are measured in 10ths and
100s of MBs ... and we have other dirs which can easily grow beyond any
limits.

Same system as before:
# du -sh /var/cache /usr
13G /var/cache
8.8G /usr

Ralf

[&quot;Jóhann B. Guðmundsson&quot;]

Post by Ralf Corsepius
C'mon, we have packages whose install-sizes are measured in 10ths and
100s of MBs ... and we have other dirs which can easily grow beyond
any limits.

I was refering to it being in the eye of the beholder so to speak but as
I see it we need to start working towards shrinking the core/base of the
distribution to the size of posted stamp compare to the bloat we are
now, to keep us agile enough and relevant for the next generation of
tinkerers "embedded" as well as to be able to serve the cloud and
container market.

In doing so we need to fix dependency and drop or make it optional to
add or remove various components ( agile ) as well as the legacy cruff
which everybody hold so dear to, in the process.

copr presents us with the ability to mapping out and make such drastic
changes without having to cause disruption to Fedora in general and
people work flows until things have been properly fixed and prepared to
do so.

Something we did not have when we decide to replace the distribution
init system.

JBG

[Martin Langhoff]

So, I'd question the usefulness of not installing man-pages, because their
sizes are comparatively small on today's disk-scales, e.g. on my primary
# du -sh /usr/share/man
89M /usr/share/man
That's almost neglibile in comparision to the overall size of the
installation.

Disk usage of many small files can be disproportionate. On some
platforms -- embedded, lightweight VMs, the savings are sometimes
important. They sure were on XO-1 not that long ago, and I'm not sure
what I'd do with docs and manages in an "on-demand" VMs.

Having said that, exclude_docs and install_langs have worked well for
OLPC and work reasonably well for lightweight VMs too.

I am not arguing for big changes here. The plans outlined seem doable,
but reworking the whole distro into doc packages to fix something that
already works /reasonably well/ seems... not cost effective.

There are some limited use cases that aren't ideal now with
install_lang and exclude_docs. For example, installing missing docs or
langs -- for all or some packages. But that seems like it could be
solved by a script that drives rpm to do just that.

cheers,




m

[James Antill]

Post by Martin Langhoff
There are some limited use cases that aren't ideal now with
install_lang and exclude_docs. For example, installing missing docs or
langs -- for all or some packages. But that seems like it could be
solved by a script that drives rpm to do just that.

While the recent "yum fs refilter" stuff tries to help here, the big
problem is that the exclude-docs/exclude-langs options are transaction
wide ... so you can't do an upgrade and have pkg X with docs and pkg Y
without.

[Billy Crook]

I would like to see logic like this:
manpage files don't get installed unless/until:
1) packagename-manpages is requested to be installed by the user. that
package would require the 'man' package.
OR
2) package is installed AND man is installed.

Don't wan't the manpages taking up disk space? remove the 'man' package
and all manpages disappear.
Don't use en_US and don't want to waste space on that either, remove the
'localization-en_US' package and its corresponding localizations of all
installed packages will dispapear too.

Localization could work the same way. Once a package' localization cruft
is large enough to merit the work, the packager would split it out into
${packagename}-en_US packages for each localization. Distro would maintain
an essentially empty package called localization-en_US, etc for each
localization. Then when you install a localized package, you get
${packagename}-en_US localization-en_us installed, and if you have more
than one localization package installed, you get the corresponding
localized subpackages of ${package}.

Post by Marius A
Hi there,
I've been struggling keeping a fedora 20 install on a "small" SSD, with
6gb / partition (/home is separate).
1. remove /usr/share/docs
2. remove /usr/share/locale/* (all except en and en_US)
3. cleanup /var/log/journal, which seems it's not automatically rotated
While this saves space, it also results in package upgrade warnings due to
missing files.
Are there any other disk space saving tips?
What do you think about excluding docs by default in Fedora packages?
And for docs either go online, or have a command to install/sync docs for
all installed packages? (similar to ruby or npm packages install, not using
rpm packages)
I think less than 0.1% of users ever look into /usr/share/doc, but I don't
have any data to back this up.
As more folks switch to SSDs, it would benefit both for disk space saving
and wearing to have less space occupied by default.
Thanks
--
devel mailing list
devel at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140409/b75b1fa8/attachment.html>

[Reindl Harald]

1) packagename-manpages is requested to be installed by the user. that package would require the 'man' package.
OR
2) package is installed AND man is installed.
Don't wan't the manpages taking up disk space? remove the 'man' package and all manpages disappear.
Don't use en_US and don't want to waste space on that either, remove the 'localization-en_US' package and its
corresponding localizations of all installed packages will dispapear too

packages i build at my own have "package-manpages" for any man/doc parts
on all the servers i maintain they are not installed
it's enough to have them on *one* central admin server

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140409/cb7a28ce/attachment.sig>

[Billy Crook]

Post by Billy Crook

Post by Billy Crook
1) packagename-manpages is requested to be installed by the user. that

package would require the 'man' package.

Post by Billy Crook
OR
2) package is installed AND man is installed.
Don't wan't the manpages taking up disk space? remove the 'man' package

and all manpages disappear.

Post by Billy Crook
Don't use en_US and don't want to waste space on that either, remove the

'localization-en_US' package and its

Post by Billy Crook
corresponding localizations of all installed packages will dispapear too

packages i build at my own have "package-manpages" for any man/doc parts
on all the servers i maintain they are not installed
it's enough to have them on *one* central admin server

heck, on my desktop I might end up just yum installing *-manpages to save
time later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140409/f5451b9f/attachment.html>

[Reindl Harald]

Post by Reindl Harald

1) packagename-manpages is requested to be installed by the user. that package would require the 'man' package.
OR
2) package is installed AND man is installed.
Don't wan't the manpages taking up disk space? remove the 'man' package and all manpages disappear.
Don't use en_US and don't want to waste space on that either, remove the 'localization-en_US' package and its
corresponding localizations of all installed packages will dispapear too

packages i build at my own have "package-manpages" for any man/doc parts
on all the servers i maintain they are not installed
it's enough to have them on *one* central admin server
heck, on my desktop I might end up just yum installing *-manpages to save time later

really?

compared how often i reinstall a workstation (never) and how often
i need a manpage because "command --help" don't answer the question
that is unlikely

how many manpages do you have installed and how many of them
you ever viewed in the past let say 5 years?

escpecially because the goal is to seperate things which does *not*
mean they are not installed in most setups - a meta-package "postfix"
can pull "postfix-server" and "postfix-manuals" while you can remove
the metapackage and "postfix-manuals"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140409/6fee505e/attachment.sig>

[Ralf Corsepius]

Post by Billy Crook
1) packagename-manpages is requested to be installed by the user. that
package would require the 'man' package.
OR
2) package is installed AND man is installed.

In other words, you want to crippled end-user usability to NULL.

Ralf

[&quot;Jóhann B. Guðmundsson&quot;]

Post by Ralf Corsepius

Post by Billy Crook
1) packagename-manpages is requested to be installed by the user. that
package would require the 'man' package.
OR
2) package is installed AND man is installed.

In other words, you want to crippled end-user usability to NULL.

I would not be dwelling to much on the usability topic since we have
bigger issues to fry then end-user usability with minimal installation
footprint for cloud/containers/servers which can be easily solve with
same concept as is behind "command-not-found" for man-pages as in
"man-page-not-found" and move cloud/container/server administration into
the realm of "install on demand" ( which arguably we should be moving
more towards at on the 21 century rather then rely on plethora of
installation commands and package names ) and ofcourse we would remove
the silliness of having to confirm the installation since I as an
administrators have already made the gesture that I need the command or
the man page when I write foo or man foo so I should not have to confirm
it to.

JBG

[Reindl Harald]

Post by Ralf Corsepius

Post by Billy Crook
1) packagename-manpages is requested to be installed by the user. that
package would require the 'man' package.
OR
2) package is installed AND man is installed.

In other words, you want to crippled end-user usability to NULL.

I would not be dwelling to much on the usability topic since we have bigger issues to fry then end-user usability
with minimal installation footprint for cloud/containers/servers which can be easily solve with same concept as is
behind "command-not-found" for man-pages as in "man-page-not-found" and move cloud/container/server administration
into the realm of "install on demand" ( which arguably we should be moving more towards at on the 21 century rather
then rely on plethora of installation commands and package names ) and ofcourse we would remove the silliness of
having to confirm the installation since I as an administrators have already made the gesture that I need the
command or the man page when I write foo or man foo so I should not have to confirm it to

no - if i type "man whatever" and that starts to pull 10 MB packages i stop
and think 5 seconds if there is one of my ,ore than 30 machines which have
it already

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140410/5a0cd06f/attachment.sig>

[&quot;Jóhann B. Guðmundsson&quot;]

Post by Reindl Harald
no - if i type "man whatever" and that starts to pull 10 MB packages i stop
and think 5 seconds if there is one of my ,ore than 30 machines which have
it already

That is you

If I was concern with that I would have done the thinking ahead of time
and simply would not have installed the "man-page-not-found" package on
those ten,hundred or thousand machines...

JBG

[Miroslav Suchý]

Post by Marius A
Are there any other disk space saving tips?

From Debian world:
https://wiki.debian.org/ReduceDebian