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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct