Gentoo Wiki:Suggestions/Archive

__NEWSECTIONLINK__ Feel free to add suggestions for our Wiki on this page. To add a new topic, click on the "+" page tab. (This might be hidden under the "more" menu.) Remember to sign your remarks with  (4 tildes), or use the "Signature and timestamp" button text-bottom|link=|signature button in the editor toolbar. See also Help:Signatures.

Stalled discussions and Archive
For discussions that haven't had contributions in a long time, see the Stalled discussions page, for completed discussion see the Archive subpage 2, Archive subpage 1.

Print to PDF and/or Export to EBook File Format?
I prefer reading long articles on my EBook Device (Kindle DXG). Seeing most documents being published in PDF, or some sites even providing EBook formats. Thankfully, my device can handle PDF but some can't. As for the Amazon Kindle's, I've seen really good results using kindlegen on converting EPUB to MOBI, but using kindlegen on HTML with TABLE TAGS produces poor MOBI files. As such, I usually use PDF files for computer technical documents. Also, kindlegen (aka mobigen) is binary only (proprietary). A couple months ago, I mirrored the entire Gentoo Documentation just to convert XML to HTML using gorg, and then kindlegen to convert to MOBI. This is very tedious for EBook users! I manage quite well as I use the console, but avoid Calibre due to it's package bloat and lack of command line only. (Calibre requires X for it's command line tool.) Probably the simple solution for now, for simple articles would be to ensure a 'Print to PDF' option. Lengthy articles such as the Gentoo Handbook and EBuild/EClass documentation, would be nice to have an EBook format. Signed: Roger 19:09, 15 November 2011 (UTC)

I second this motion as far as PDF and ePUB goes. I even submitted a wish/bug to Gentoo's Bugzilla about this. Hook 00:14, 24 March 2012 (UTC)

Count my vote as well for this notion. --Maffblaster (talk) 19:16, 3 February 2015 (UTC)

Definition of Macros
Dear wiki-admins,

You should define some macros as soon as possible for things like referencing portage packages, infoboxes for software that autocomplete from portage information, general infoboxes for software that include fields such as 'deprecated by', and create categories for each of the Gentoo projects (Hardened, etc.) so that relevant articles can be grouped together in a way that makes sense for users coming from other sources of documentation.

Voltaire 00:02, 2 August 2012 (UTC)


 * We will definitely also need one for man pages. Like 'man 5 corosync.conf' should be possible to define with a quick macro that makes it obviously possible to type at the terminal but also clickable in-wiki to go to a hosted, HTML version of the man page.  This should be the latest version auto-built out of portage, or preferably a diffed history of versions. This sort of cross-linking is precisely where a lot of Linux documentation falls down and where the Gentoo community could showcase its pragmatism. Voltaire 00:30, 4 August 2012 (UTC)

A few suggestion
For Users
 * Display last modify date and last modify editor on each wiki page to let user know about the status of the docs.
 * Having Version tag, if the package need some different configuration we can have a version tag there to change the need but not the whole page. Even-thought gentoo are always updated it is still good to kept some history.
 * Kernel Template should have a format for kernel version -- it will be easier for other to understand and update.
 * Files Template should have some way to indication changes required. Current way is to paste the whole file and looking for changes are not good for users.

For Editor
 * New Page Template -- There should be a new page template which something like prerequisite, kernel requirement, emerge application files changes blah blah blah until the End to rc-update. This would be good for new and old editor as in future when there are some new things can be added in.
 * Kernel Template should be easier to use so should have a field like enable or disable and the kernel_module_name/the long name
 * Conflict in changes should have diff on top before the editor/content, this is easier to verify.

--dcmwai (talk) 05:10, 19 February 2014 (UTC)


 * ill second the need for version tagging configurations. samba 3 vs samba 4 are radical departures from each other.666threesixes666 (talk) 05:14, 19 February 2014 (UTC)

Template for well known overlays
It would be nice to have a wiki template to create links to well known overlays pointing to more information about those. I'm typically linking either to gpo.zugaina.org overlay pages, occasionally to the actual repositories. It would be nice to have a unified target, whether it is zugaina, an equivalent, or even a wiki space where more information can be specified.

--Pavlix (talk) 14:46, 1 January 2015 (UTC)

Consistency in article titles
I would like to suggest moving the GNOME "configuration" page to GNOME/HOWTO in order to match the title style of the other HOWTO articles. Either that or change HOWTO articles to "X/Configuration" instead of having "HOWTO" in title of the articles. This would maintain consistency throughout the wiki and make the titles easier to search. I could make the changes myself but I would need admin privileges to move a page and it's probably best to actually have input on this type of change... ;) I can continue to post other inconsistencies as I discover them.

Articles using "Configuration" in their titles:

GNOME/Configuration

Xorg/Configuration

Articles using "HOWTO" in their titles:

Openbox/HOWTO

Xfce/HOWTO

--Maffblaster (talk) 19:16, 3 February 2015 (UTC)


 * I think "HOWTO" does not really convey much information about the guide, so I prefer to use a noun or title that reflects the content better. If the guide is about the configuration of a tool or service, then "Configuration" makes more sense.
 * I wouldn't go as fas as to start moving/renaming articles because of this - first work on content, we can rename later when there's a global consensus to do so ;-)
 * --SwifT (talk) 18:38, 2 March 2015 (UTC)

Link colors
I've noticed that visited links on pages such as AMD64/FAQ are almost completely indistinguishable from the surrounding normal text (I'm using Google Chrome on a Windows 8 machine with an LCD monitor). Is the visited-link color darker than it used to be? Can it be lightened a bit? - dcljr (talk) 23:46, 11 February 2015 (UTC)
 * Hmm. Looks OK again on my Firefox/Gentoo/LCD combo here at home. The Windows machine I was using just had an exceptionally narrow font (relative to the screen resolution, anyway), which made seeing the color on visited links really difficult. And BTW, probably any other article here would be a much better example, since the article I cited has very few internal links in it. That's just the article I happened to be working on at the time. [g] - dcljr (talk) 18:58, 12 February 2015 (UTC)


 * I did have my own difficulties seeing visited links at times, so let's try a different color now. Feedback welcome (it may take a while for all caches to update the CSS). —a3li 18:42, 27 February 2015 (UTC)

Gentle introduction
Seems like we need a general introduction to Gentoo Linux article (we don't already have one, right?) that covers why one would choose this distro over any of the others and, let's be honest, why one might not want to use it. (The Handbook is too oriented towards the actual installation process to serve this purpose well.) - dcljr (talk) 22:28, 14 February 2015 (UTC)


 * Hi Dcljr, a similar article called Benefits_of_Gentoo does exist, but as the title suggests it only lists the benefits. Maybe some disadvantages could be added, the layout changed, and it could be moved to the title you suggested? I would be willing to help with this, as I do have some disadvantages in mind. What do you think? --Maffblaster (talk) 19:57, 17 February 2015 (UTC)


 * You should add this to the Gentoo Wiki:Requested Articles page! —a3li 18:44, 27 February 2015 (UTC)

Homepage Infobox internal link capability
I was working on the Gentoolkit article today (it is on my list of articles to clean up) and I came across a problem: there is no way for me to properly add a link to the Infobox for an internal homepage. The homepage Infobox presumes the homepages for various software is external to the wiki. In the case of Gentoolkit (Project:Portage-Tools) the homepage is now local to the wiki. I'm sure this applies to other Gentoo-original tools that have moved their project pages to the wiki. Right now links will always appear to be "pointing" to an external location (the up-arrow graphic following the link) when that no longer the case for certain projects. My suggestion is to enable internal the ability to link internally for homepage Infoboxes. --Maffblaster (talk) 19:51, 17 February 2015 (UTC)

Formatting of keywords
I've just created Template:Keyword for formatting mentions of keywords (like ). I chose &lt;code> tags for no particularly compelling reason. Interested parties should discuss there how we should format keywords on this wiki. - dcljr (talk) 00:17, 21 February 2015 (UTC)

CSS formatting of headers: needs more colour
As a prospective new Gentoo user, I make a heavy use of this wiki in general and of the Installation Guide in particular. Two things stroke me from the start: 1) is the high quality of the documentation, for which I am very grateful to the wiki editors. 2) the poor css styling of headers which make scanning a page very difficult. The table of content at the top of each page make the structure of the page very clear. However, scanning down the the page, I must concentrate on noticing the subtle font changes to figure out where the headers are (html h2, h3, h4, etc.). Generally speaking, I find it very difficult to follow a structure on all sites that rely on subtle font style and font size differences to suggest headings. I think the css styling must include colours and styling that make the hierarchy of headings very clear (user coloured background, coloured underlines, coloured fonts, etc.). The result must achieve two goals: a) make scanning a article for a specific heading very easy. b) show clearly the hierarchy. This is all the more important for long pages, like the full installation guide on one page. Thanks. Augustin (talk) 12:38, 25 February 2015 (UTC)


 * Thanks for your feedback. Tackling this is difficult, as fixing this too much will disturb the reading flow even more.
 * I've changed two things: The headings are slightly increased in size and &lt;h2> has a slight border on the bottom to give pages some structure, like on the original Wikipedia skin. Using colors or colored backgrounds is something that would distract more than help in my opinion. Then again, I really hate having these overly long pages, but that cannot be helped. :(
 * The changes can take a day or two to pass through all caches, but do let me know if it improves things for you. —a3li 19:17, 27 February 2015 (UTC)

All-arches handbook sections
Unless I'm missing something, we have per-arch pages for parts and sections of the Handbook (e.g., Handbook:AMD64/Full/Installation and Handbook:AMD64/Installation/Disks), but we don't have pages for parts and sections that could be used for any arch. I don't mean that the pages would contain actual arch-agnostic instructions, but that they would simply link to separate pages for all the different arches (like Wikipedia disambiguation pages, except that [most] incoming links wouldn't be mistakes that need correcting, they would be intentional). That way, in an arch-agnostic article about a piece of hardware or software, for example, we could link to pages like Handbook:Installation or Handbook:Installation/Disks that would then allow users to get to the arch-specific Handbook pages they need. Right now, a lot of links to sections within the handbook seem to link to the X86 version specifically, for no good reason. - dcljr (talk) 00:00, 4 March 2015 (UTC)