Hi Dusty,
Yes, I understand your point. Cloud images are usually spun up and provisioned automatically by cloud service providers, but they are often used as regular remote machines by end users.
E.g. Scaleway offers a selection of "curated" cloud images for their servers (for Fedora: https://github.com/scaleway/image-fedora) that the user can choose from, which have been tested and customized with their provisioning scripts. Which is not without issues but they sort them out at GitHub.
From an end-user perspective though, even if I was provisioning the server through some automatic tool like Terraform (https://www.terraform.io/), I expect the operating system to be working just as a regular Fedora system would. Even if it's a stripped-down minimal version, I could install anything necessary for my tasks.
That's why I'm using Fedora in the first place, because it's familiar and contains the latest necessary software.
The problem with the missing man pages from an end-user perspective:
- This seems to be a bug at first glance (at first I thought it's a Scaleway deployment issue)
- It's not documented inside the image
- It's not documented outside of the image in some official documentation
For an experienced user, a warning message would sufficient to know where to look at least - to know why this is happening and how to solve the situation if necessary.
This wouldn't be the responsibility of the man software (in package man-db) because this is package manager stuff.
So my solution proposal:
- I'm going to create PRs to add this piece of info to the Scaleway Fedora (https://github.com/scaleway/image-fedora), Docker Brew (https://github.com/fedora-cloud/docker-brew-fedora), and possibly Docker library (https://hub.docker.com/_/fedora/) readmes. Just a warning that documentation has been permanently turned off, referencing to this discussion: https://github.com/fedora-cloud/docker-brew-fedora/issues/9
- I'll create an RFE for DNF (instead of man) - to show a warning when tsflags have been set. Even something like: "Current transaction flags: [...]" would be sufficient. This at least informs the user about the configuration.
What do you think?
Best regards,
Greg
On jún 28 2018, at 3:03 du, Dusty Mabe <dusty@xxxxxxxxxxxxx> wrote:
On 06/28/2018 05:38 AM, Gergely Gombos wrote:Hello,Hi Greg,I just installed a F28 image on a Scaleway cloud server. Runs fine, except there were no man pages, even after installing man-pages package.It turned out after a lot of searching that this is not a bug but a feature.Issue on GitHub: https://github.com/fedora-cloud/docker-brew-fedora/issues/9#issuecomment-365176011So the culprit is the Kickstarts file, here: https://pagure.io/fedora-kickstarts/blob/master/f/fedora-docker-common.ks#_32 (and other nearby .ks files)It says "%packages --excludedocs --instLangs=en --nocore [...]"According to the Kickstart docs (http://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#chapter-4-package-selection) this won't install man pages, presumably to save space, but the end user won't know this, because man will simply not find any man pages and that's it.A solution was to edit /etc/dnf/dnf.conf, comment "tsflags=nodocs" and then reinstall everything with dnf reinstall.My question: I understand that it's important to save space with containers, but often cloud users wish to use man pages, as they are using the cloud server just as any remote computer. Is there a way to document the above situation e.g. when the user tries to view a man page gets a notification about why they are not installed (and how to install them)?This is subjective to who you are, but here is my opinion. A "Cloud" server isusually one that is spun up and provisioned automatically (i.e. a person doesnot SSH into the machine to configure it). The cloud instance has a specificpurpose and can be thrown away easily and re-provisioned. In this scenario docsare wasted space and people generally value smaller image size over having thedocumentation.Now there are certainly cases where you just spin up a cloud instance and wantto configure it yourself, but that's not what we're optimizing for. It would benice if 'man' were able to detect this situation and offer an alternative. Maybeopen an RFE BZ against man for this??- Dusty
_______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/cloud@xxxxxxxxxxxxxxxxxxxxxxx/message/PQC55BB4UFCJE5TV2DUIUY72L26EP3PK/