Difference between pages "Adding an Ebuild to the Wiki" and "Applying Local Patches to Ebuilds"

(Difference between pages)
 
 
Line 1: Line 1:
This page describes how to add an official entry for an ebuild to the Funtoo Linux wiki.
+
This page documents how to apply your own local patches to ebuilds when they are built, without having to actually modify the ebuild itself.
  
== Goal ==
+
== Installation ==
 +
First, install {{Package|app-portage/foobashrc}}:
 +
<console># ##i##emerge app-portage/foobashrc</console>
 +
This will install the script foobashrc.bashrc at /etc/portage/. It is intended to be used in the emerge process through /etc/portage/bashrc (see [http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=6#doc_chap3 Hooking In the Emerge Process (Gentoo Manual)]). If you do not have your own bashrc yet, you can just link it to foobashrc.bashrc:
 +
<console># ##i##ln -s /etc/portage/foobashrc.bashrc /etc/portage/bashrc</console>
 +
To complete the installation you need to add
  
Our goal for ebuild wiki pages is ambitious -- the wiki should have complete and excellent documentation for using every ebuild in Portage. If the ebuild exists in your Funtoo Linux Portage tree, and there is no corresponding ebuild page for it, you're encouraged to use these instructions to add a page to the wiki for it.
+
<pre>
 +
foobashrc_modules = "localpatch"
 +
</pre>
 +
to your /etc/make.conf. By un-/commenting this line you can easily activate/deactivate localpatch.
  
== What We Have So Far ==
+
== How it works ==
  
To see what ebuild pages we have so far, see the [[Ebuilds by CatPkg]] page to see if the "CatPkg" (category/package atom) is already on this wiki.  
+
By default, localpatch will look into /etc/portage/localpatches in order to search for patches. This can be changed by setting LOCALPATCH_OVERLAY variable within /etc/make.conf.
  
You can also view all pages having to do with ebuilds (which also includes Package pages themselves) by going to the [[:Category:Ebuilds]] page. Package pages will be listed by their regular wiki page names, which may make them harder to find.
+
The actual patches for a package are placed in subdirectories with one of the following naming schemata:
 +
# ${CATEGORY}/${PN}-${PV}-${PR} - example 'app-foo/bar-1.0-r1'
 +
# ${CATEGORY}/${PN}-${PV} - example 'app-foo/bar-1.0'
 +
# ${CATEGORY}/${PN} - example 'app-foo/bar'
 +
Only the patches within the first matching schema are used and are applied within numerical order.
  
== The Package Namespace ==
 
 
This wiki has a special MediaWiki [http://www.mediawiki.org/wiki/Help:Namespaces namespace] called <code>Package</code>. Pages in this namespace have a URL that is prefixed with <code>Package:</code>, such as this wiki page: [[Package:Accelerated AMD Video Drivers]], which is also a good example of a wiki page for an ebuild.
 
 
== An Example Ebuild Page ==
 
 
Let's look at an ebuild page: [[Package:Accelerated AMD Video Drivers]]. You'll notice it has a unique look that is distinct from a regular wiki page.
 
 
There are several other notable things about package pages. Let's take a look at each:
 
 
* As covered earlier, the ebuild is in the Package namespace.
 
* The ebuild is in the [[:Category:Ebuilds]] category.
 
* In the left-hand Tools menu, you can click <code>Browse Properties</code> on an Ebuild page to view its queryable semantic properties.
 
* There is an infobox in the upper-right corner that lists current ebuild maintainer, and the source repository to which it belongs, as well as its official CatPkg name.
 
 
'''One of the most important things to note about this Ebuild page is the name of the wiki page itself.''' Rather than being named <code>x11-drivers/ati-drivers</code>, as the ebuild is identified in the Portage tree, it has a regular English name as the wiki page name. Some ebuilds, like the [[Package:Nginx]] page, have the regular package name as the wiki page name. The general rule for naming ebuild pages is that they should be named as a regular wiki page, with a descriptive English name in the Package namespace. The Package namespace (as well as being part of the [[:Category:Ebuilds]] category) indicates that this page is about a Package (ebuild.)
 
 
The rationale for this convention is to improve discoverability of these pages via search engines, and to align with wiki page conventions. The CatPkg is stored as semantic data so it is still possible to find the page using its traditional package atom.
 
 
== Semantic Data ==
 
 
The following semantic data is stored for each Package page:
 
 
* [[Property:CatPkg|CatPkg]] (string) - the canonical name (catpkg atom) for the package in its overlay or repository.
 
* [[Property:Maintainer|Maintainer]] (Page) - a link to the maintainer(s) of this package (if the user has a User page, it will link there.) Important for forked ebuilds. Can be left blank.
 
* [[Property:Repository|Repository]] (Page) - a link to the repository from which this ebuild is sourced. This can be an overlay or a full Portage tree. This information is filled out automatically.
 
* [[Property:Summary|Summary]] (Text) - a short summary, typically a sentence, that describes the functionality of the ebuild.
 
 
To extract some of this information:
 
example extraction of gnome mastermind's information
 
<console>$##i## equery m games-board/gnome-mastermind</console>
 
<console>$##i## cat /usr/portage/games-board/gnome-mastermind/gnome-mastermind-*.ebuild | grep DESCRIPTION</console>
 
 
== Creating a Package Page ==
 
 
To add an Ebuild page to the wiki, use the widget below, which will pop up a form to guide you through the creation process. Remember the naming guidelines... If you were creating a wiki page for <code>www-servers/apache</code>, you would probably name the wiki page "Apache" or "Apache Web Server", and ''then'' enter <code>www-servers/apache</code> as the ''CatPkg'' on the form.
 
 
You will also be prompted for a Summary and Maintainer. The maintainer field will auto-complete, based on Users defined on the wiki. If you don't know the maintainer, leave it blank -- a staff member will fill it in properly for you. Our main goal is to get ''quality documentation'' online, so if you can help with that, fantastic!
 
 
{{#forminput:form=Ebuild|size=|default value=|button text=Add Package|autocomplete on namespace=Package|remote autocompletion|placeholder=Descriptive name|query string=namespace=Package}}
 
 
== Pages Need Approval ==
 
 
Anyone who signs up for a Funtoo account can create and edit wiki pages, but your additions/changes may need to be approved by a moderator before they are displayed. You can still edit and improve the page in the mean time. Once your edits have been approved, your changes will be on the official page that is displayed when anyone visits it.
 
 
Thanks very much for your contribution to Funtoo Linux documentation!
 
  
 +
[[Category:Projects]]
 
[[Category:Portage]]
 
[[Category:Portage]]
[[Category:Needs Updates]]
+
[[Category:Labs]]

Latest revision as of 05:28, June 28, 2014

This page documents how to apply your own local patches to ebuilds when they are built, without having to actually modify the ebuild itself.

Installation

First, install app-portage/foobashrc (package not on wiki - please add):

# emerge app-portage/foobashrc

This will install the script foobashrc.bashrc at /etc/portage/. It is intended to be used in the emerge process through /etc/portage/bashrc (see Hooking In the Emerge Process (Gentoo Manual)). If you do not have your own bashrc yet, you can just link it to foobashrc.bashrc:

# ln -s /etc/portage/foobashrc.bashrc /etc/portage/bashrc

To complete the installation you need to add

foobashrc_modules = "localpatch"

to your /etc/make.conf. By un-/commenting this line you can easily activate/deactivate localpatch.

How it works

By default, localpatch will look into /etc/portage/localpatches in order to search for patches. This can be changed by setting LOCALPATCH_OVERLAY variable within /etc/make.conf.

The actual patches for a package are placed in subdirectories with one of the following naming schemata:

  1. ${CATEGORY}/${PN}-${PV}-${PR} - example 'app-foo/bar-1.0-r1'
  2. ${CATEGORY}/${PN}-${PV} - example 'app-foo/bar-1.0'
  3. ${CATEGORY}/${PN} - example 'app-foo/bar'

Only the patches within the first matching schema are used and are applied within numerical order.