Difference between revisions of "Forking An Ebuild"
| Line 3: | Line 3: | ||
== Portage Tree Generation == | == Portage Tree Generation == | ||
| − | Funtoo Linux generates its Portage tree using a special script that essentially takes a gentoo tree as its starting point, and then applies various modifications to it. The modifications involve adding packages from various overlays, including our [[Overlay:Funtoo overlay]]. Some packages are brand new, while other packages are our special forked versions that replace existing packages. In the vast majority of cases, when we fork a package, we take full responsibility for all ebuilds associated with that package, meaning that we have a full copy of the <tt>sys-foo/bar</tt> directory in one of our overlays. | + | Funtoo Linux generates its Portage tree using a special script that essentially takes a gentoo tree as its starting point, and then applies various modifications to it. The modifications involve adding packages from various overlays, including our [[Overlay:Funtoo-overlay]]. Some packages are brand new, while other packages are our special forked versions that replace existing packages. In the vast majority of cases, when we fork a package, we take full responsibility for all ebuilds associated with that package, meaning that we have a full copy of the <tt>sys-foo/bar</tt> directory in one of our overlays. |
[[Category:Development]] | [[Category:Development]] | ||
Revision as of 03:41, 21 January 2013
Often, a Funtoo developer needs to fork an upstream ebuild. This is necessary when we want to apply fixes to it. This page will explain the concepts of forking and how this works in the context of Funtoo.
Portage Tree Generation
Funtoo Linux generates its Portage tree using a special script that essentially takes a gentoo tree as its starting point, and then applies various modifications to it. The modifications involve adding packages from various overlays, including our Overlay:Funtoo-overlay. Some packages are brand new, while other packages are our special forked versions that replace existing packages. In the vast majority of cases, when we fork a package, we take full responsibility for all ebuilds associated with that package, meaning that we have a full copy of the sys-foo/bar directory in one of our overlays.
