2:33 a.m.
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
4:37 a.m.
On Wed, Apr 9, 2014 at 10:33 AM, Marius A <marius1439(a)gmail.com> wrote:
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
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.
2:57 p.m.
On Wed, 2014-04-09 at 12:37 +0300, Ville Skyttä wrote:
On Wed, Apr 9, 2014 at 10:33 AM, Marius A
<marius1439(a)gmail.com> wrote:
> 1. remove /usr/share/docs
Try this in /etc/rpm/macros.whatever:
%_excludedocs 1
For recent yum it's significantly better to do:
yum fs filter nodocs
Try this in /etc/rpm/macros.whatever:
%_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.
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.
3:41 p.m.
On Wed, Apr 09, 2014 at 03:57:27PM -0400, James Antill wrote:
For recent yum it's significantly better to do:
yum fs filter nodocs
Dito. to get rid of extra languages by:
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?
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
8:49 a.m.
On Wed, 2014-04-09 at 16:41 -0400, Matthew Miller wrote:
On Wed, Apr 09, 2014 at 03:57:27PM -0400, James Antill wrote:
> For recent yum it's significantly better to do:
> yum fs filter nodocs
> Dito. to get rid of extra languages by:
> 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.
2:42 a.m.
On Wed, Apr 9, 2014 at 10:57 PM, James Antill <james(a)fedoraproject.org>wrote:
On Wed, 2014-04-09 at 12:37 +0300, Ville Skyttä wrote:
> On Wed, Apr 9, 2014 at 10:33 AM, Marius A <marius1439(a)gmail.com> wrote:
> > 1. remove /usr/share/docs
>
> Try this in /etc/rpm/macros.whatever:
> %_excludedocs 1
For recent yum it's significantly better to do:
yum fs filter nodocs
> Try this in /etc/rpm/macros.whatever:
> %_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.
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 :)
8:56 a.m.
On Thu, 2014-04-10 at 10:42 +0300, Marius A wrote:
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.
8:14 p.m.
On Thu, 2014-04-10 at 09:56 -0400, James Antill wrote:
On Thu, 2014-04-10 at 10:42 +0300, Marius A wrote:
> 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?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:52 p.m.
On Thu, 2014-05-15 at 18:14 -0700, Adam Williamson wrote:
On Thu, 2014-04-10 at 09:56 -0400, James Antill wrote:
> On Thu, 2014-04-10 at 10:42 +0300, Marius A wrote:
>
> > 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>
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.
4:15 p.m.
On Fri, 2014-05-16 at 14:52 -0400, James Antill wrote:
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)?
8:27 p.m.
On 04/09/2014 12:57 PM, James Antill wrote:
On Wed, 2014-04-09 at 12:37 +0300, Ville Skyttä wrote:
> On Wed, Apr 9, 2014 at 10:33 AM, Marius A <marius1439(a)gmail.com> wrote:
>> 1. remove /usr/share/docs
>
> Try this in /etc/rpm/macros.whatever:
> %_excludedocs 1
For recent yum it's significantly better to do:
yum fs filter nodocs
> Try this in /etc/rpm/macros.whatever:
> %_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.
> 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
--
J. Randall Owens | http://www.ghiapet.net/
6:23 a.m.
On 04/09/2014 09:33 AM, Marius A wrote:
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
6:50 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/09/2014 07:23 AM, "Jóhann B. Guðmundsson" wrote:
On 04/09/2014 07:33 AM, Marius A wrote:
>
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlNFNA0ACgkQeiVVYja6o6P3SgCfRoJnKbSe/2g6/HIZkzkYAJRc
iDcAoKRygNTlNDEIbf8j46e94RowXtis
=OpG3
-----END PGP SIGNATURE-----
7:03 a.m.
On 04/09/2014 11:50 AM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/09/2014 07:23 AM, "Jóhann B. Guðmundsson" wrote:
> On 04/09/2014 07:33 AM, Marius A wrote:
>> 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
7:39 a.m.
On Wed, Apr 09, 2014 at 07:50:37AM -0400, Stephen Gallagher wrote:
> 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_pack...
could be a model (and is in fact a prerequisite).
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
9:53 a.m.
On Wed, 2014-04-09 at 08:39 -0400, Matthew Miller wrote:
On Wed, Apr 09, 2014 at 07:50:37AM -0400, Stephen Gallagher wrote:
> > 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
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).
10:12 a.m.
On 04/09/2014 04:53 PM, Matthias Clasen wrote:
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.
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.
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*
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
7:42 a.m.
On 04/09/2014 01:50 PM, Stephen Gallagher wrote:
On 04/09/2014 07:23 AM, "Jóhann B. Guðmundsson" wrote:
> On 04/09/2014 07:33 AM, Marius A wrote:
>>
>> 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
10:23 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/09/2014 08:42 AM, Florian Festi wrote:
On 04/09/2014 01:50 PM, Stephen Gallagher wrote:
> On 04/09/2014 07:23 AM, "Jóhann B. Guðmundsson" wrote:
>
>> On 04/09/2014 07:33 AM, Marius A wrote:
>>>
>>> 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
This construct would be extremely valuable to the SSSD as well:
%package -n client
Recommends: sssd-client.i686 if glibc.i686
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.
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlNFZeQACgkQeiVVYja6o6Nv7ACgom5qypruoq68WLtnFqLydelm
ykkAn21vSW53VnMypMNz+amO9AaTfKrl
=CKpf
-----END PGP SIGNATURE-----
10:35 a.m.
On 04/09/2014 05:23 PM, Stephen Gallagher wrote:
This construct would be extremely valuable to the SSSD as well:
%package -n client
Recommends: sssd-client.i686 if glibc.i686
That's not exactly by accident...
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.
> 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
1:42 p.m.
Florian Festi (ffesti(a)redhat.com) said:
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
4:10 p.m.
On 04/09/2014 08:42 PM, Bill Nottingham wrote:
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
9:28 a.m.
On Wed, 2014-04-09 at 23:10 +0200, Florian Festi wrote:
On 04/09/2014 08:42 PM, Bill Nottingham wrote:
> 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.
11:05 a.m.
James Antill (james(a)fedoraproject.org) said:
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
12:13 p.m.
On 10/04/14 17:05, Bill Nottingham wrote:
James Antill (james(a)fedoraproject.org) said:
> 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@phanto ~]# cd /usr/share
[root@phanto share]# cp -r locale locale-compressed
[root@phanto share]# find locale-compressed -type f -name '*.mo' -exec
bzip2 --best {} \;
[root@phanto share]# du -sh locale locale-compressed
657M locale
245M locale-compressed
(NB this isn't a newly installed system.)
Andy
3:54 p.m.
On Thu, Apr 10, 2014 at 06:13:42PM +0100, Andrew Price wrote:
On 10/04/14 17:05, Bill Nottingham wrote:
>James Antill (james(a)fedoraproject.org) said:
>> 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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
2:15 p.m.
On 11/04/14 21:54, Richard W.M. Jones wrote:
On Thu, Apr 10, 2014 at 06:13:42PM +0100, Andrew Price wrote:
> On 10/04/14 17:05, Bill Nottingham wrote:
>> James Antill (james(a)fedoraproject.org) said:
>>> 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
2:53 p.m.
On Thu, 2014-04-10 at 12:05 -0400, Bill Nottingham wrote:
James Antill (james(a)fedoraproject.org) said:
> 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
2:05 a.m.
On 04/10/2014 09:53 PM, James Antill wrote:
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.
same thing for updates gives:
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
12:23 p.m.
On 9 April 2014 22:10, Florian Festi <ffesti(a)redhat.com> wrote:
On 04/09/2014 08:42 PM, Bill Nottingham wrote:
> 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.
--
Peter Oliver
1:45 p.m.
On 04/10/2014 01:23 PM, Peter Oliver wrote:
On 9 April 2014 22:10, Florian Festi <ffesti(a)redhat.com>
wrote:
>
> On 04/09/2014 08:42 PM, Bill Nottingham wrote:
>> 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).
--
Libre Video
http://librevideo.org
8:25 a.m.
On Wed, Apr 09, 2014 at 10:33:25AM +0300, Marius A wrote:
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.
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
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.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
8:53 a.m.
On 04/09/2014 03:33 AM, Marius A wrote:
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.
--
Libre Video
http://librevideo.org
9:01 a.m.
On Wed, Apr 09, 2014 at 09:53:10AM -0400, Basil Mohamed Gohar wrote:
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.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
9:10 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/09/2014 10:01 AM, Matthew Miller wrote:
On Wed, Apr 09, 2014 at 09:53:10AM -0400, Basil Mohamed Gohar
wrote:
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlNFVN0ACgkQeiVVYja6o6OBywCgrYgmx8fjMrhIRLHLwPc8g9jv
NGQAoKudkM+C7x56tY8bwjXE3ziCUKOT
=b7Cg
-----END PGP SIGNATURE-----
9:13 a.m.
On Wed, Apr 09, 2014 at 10:10:37AM -0400, Stephen Gallagher wrote:
>> 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.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
9:19 a.m.
On 04/09/2014 04:01 PM, Matthew Miller wrote:
On Wed, Apr 09, 2014 at 09:53:10AM -0400, Basil Mohamed Gohar wrote:
> 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
9:31 a.m.
On 04/09/2014 03:53 PM, Basil Mohamed Gohar wrote:
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
9:49 a.m.
On 04/09/2014 02:31 PM, Ralf Corsepius wrote:
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
9:55 a.m.
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(a)gmail.com
wrote:
On 04/09/2014 02:31 PM, Ralf Corsepius wrote:
>
> 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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
9:57 a.m.
On Wed, Apr 9, 2014 at 10:49 AM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
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.
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
--
martin.langhoff(a)gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
9:59 a.m.
On Wed, Apr 09, 2014 at 02:49:56PM +0000, "Jóhann B. Guðmundsson" wrote:
>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
10 a.m.
On 04/09/2014 02:59 PM, Alexey I. Froloff wrote:
On Wed, Apr 09, 2014 at 02:49:56PM +0000, "Jóhann B.
Guðmundsson" wrote:
>> 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
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
10:16 a.m.
On Wed, Apr 09, 2014 at 03:00:24PM +0000, "Jóhann B. Guðmundsson" wrote:
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.
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
11:14 a.m.
On 04/09/2014 04:49 PM, "Jóhann B. Guðmundsson" wrote:
On 04/09/2014 02:31 PM, Ralf Corsepius wrote:
>
> 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).
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
11:54 a.m.
On 04/09/2014 04:14 PM, Ralf Corsepius wrote:
>
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
9:54 a.m.
On Wed, Apr 9, 2014 at 10:31 AM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
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.
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
--
martin.langhoff(a)gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
3 p.m.
On Wed, 2014-04-09 at 10:54 -0400, Martin Langhoff wrote:
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.
3:05 p.m.
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}.
On Wed, Apr 9, 2014 at 2:33 AM, Marius A <marius1439(a)gmail.com> wrote:
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
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
3:41 p.m.
Am 09.04.2014 22:05, schrieb 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
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
4:01 p.m.
On Wed, Apr 9, 2014 at 3:41 PM, Reindl Harald <h.reindl(a)thelounge.net>wrote:
Am 09.04.2014 22:05, schrieb 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
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.
4:19 p.m.
Am 09.04.2014 23:01, schrieb Billy Crook:
On Wed, Apr 9, 2014 at 3:41 PM, Reindl Harald
<h.reindl(a)thelounge.net <mailto:h.reindl@thelounge.net>> wrote:
Am 09.04.2014 22:05, schrieb 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
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"
4:12 p.m.
On 04/09/2014 10:05 PM, Billy Crook wrote:
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.
In other words, you want to crippled end-user usability to NULL.
Ralf
5 p.m.
On 04/09/2014 09:12 PM, Ralf Corsepius wrote:
On 04/09/2014 10:05 PM, Billy Crook wrote:
> 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.
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
5:06 p.m.
Am 10.04.2014 00:00, schrieb Jóhann B. Guðmundsson:
On 04/09/2014 09:12 PM, Ralf Corsepius wrote:
> On 04/09/2014 10:05 PM, Billy Crook wrote:
>> 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.
>
> 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
5:13 p.m.
On 04/09/2014 10:06 PM, Reindl Harald wrote:
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
2:59 a.m.
On 04/09/2014 09:33 AM, Marius A wrote:
Are there any other disk space saving tips?
From Debian world:
https://wiki.debian.org/ReduceDebian
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
3633
days inactive
3670
days old
57 comments
23 participants
participants (23)
-
Adam Williamson -
Alexey I. Froloff -
Andrew Price -
Basil Mohamed Gohar -
Bill Nottingham -
Billy Crook -
Corey Sheldon -
Florian Festi -
J. Randall Owens -
James Antill -
Jóhann B. Guðmundsson -
Marius A -
Martin Langhoff -
Matthew Miller -
Matthias Clasen -
Michal Schmidt -
Miroslav Suchý -
Peter Oliver -
Ralf Corsepius -
Reindl Harald -
Richard W.M. Jones -
Stephen Gallagher -
Ville Skyttä