Forking An Ebuild - Revision history

Palica at 21:18, 21 January 2013

2013-01-21T21:18:59Z

Drobbins: /* Funtoo-ification */

2013-01-21T04:12:33Z

‎Funtoo-ification

Drobbins at 04:11, 21 January 2013

2013-01-21T04:11:34Z

Drobbins at 04:03, 21 January 2013

2013-01-21T04:03:53Z

Drobbins at 03:56, 21 January 2013

2013-01-21T03:56:11Z

Drobbins at 03:53, 21 January 2013

2013-01-21T03:53:15Z

Drobbins at 03:41, 21 January 2013

2013-01-21T03:41:10Z

Drobbins at 03:40, 21 January 2013

2013-01-21T03:40:40Z

Drobbins: Created page with "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 wo..."

2013-01-21T03:40:15Z

Created page with "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 wo..."

New page

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 <tt>sys-foo/bar</tt> directory in one of our overlays.

[[Category:Development]]

@@ Line 3: / Line 3: @@
 == 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 added are brand new, while other packages are our special forked versions that replace existing packages.
+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 added 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.

@@ Line 37: / Line 37: @@
 # Line length greater than 80 characters. Gentoo enforces an 80-character line length limit. We don't.
-# <tt>KEYWORDS<tt> of <tt>*</tt> and <tt>~*</tt>. Gentoo does not allow these shortcuts. We do. They allow you to say "all arches" and "all unstable arches" in a concise way. Gentoo doesn't allow these shortcuts because it's Gentoo's policy to have each arch team manually approve each package. We do not have this policy so we can use the shortcuts.
+# <tt>KEYWORDS</tt> of <tt>*</tt> and <tt>~*</tt>. Gentoo does not allow these shortcuts. We do. They allow you to say "all arches" and "all unstable arches" in a concise way. Gentoo doesn't allow these shortcuts because it's Gentoo's policy to have each arch team manually approve each package. We do not have this policy so we can use the shortcuts.
 # Use of <tt>4-python</tt> EAPI. We allow the use of this EAPI for enhanced python functionality.
 [[Category:Development]]

← Older revision		Revision as of 04:11, 21 January 2013
Line 25:		Line 25:

	At this point, the forked <tt>sys-foo/bar</tt> package will be part of funtoo-overlay. The next time our unified Portage tree is generated by <tt>merge.py</tt> (the one that users have in their <tt>/usr/portage</tt> and is updated via <tt>emerge --sync</tt>), your forked ebuild will be used in place of the Gentoo ebuild. Why is this? It is because our <tt>merge.py</tt> script has been defined with a policy that any ebuilds in funtoo-overlay will replace any existing Gentoo ebuilds if they exist. The mechanism of replacement is that our <tt>sys-foo/bar</tt> directory will be used in place of Gentoo's <tt>sys-foo/bar</tt> directory. So this is how the forking process works.		At this point, the forked <tt>sys-foo/bar</tt> package will be part of funtoo-overlay. The next time our unified Portage tree is generated by <tt>merge.py</tt> (the one that users have in their <tt>/usr/portage</tt> and is updated via <tt>emerge --sync</tt>), your forked ebuild will be used in place of the Gentoo ebuild. Why is this? It is because our <tt>merge.py</tt> script has been defined with a policy that any ebuilds in funtoo-overlay will replace any existing Gentoo ebuilds if they exist. The mechanism of replacement is that our <tt>sys-foo/bar</tt> directory will be used in place of Gentoo's <tt>sys-foo/bar</tt> directory. So this is how the forking process works.
		+
		+	== Funtoo-ification ==
		+
		+	When we fork a package from Gentoo, we perform the following tweaks to the package directory before committing:
		+
		+	# Removal of <tt>ChangeLog</tt>.
		+	# Run <tt>ebuild foo-1.0.ebuild digest</tt> before committing. This will cause the <tt>Manifest</tt> file to be regenerated. Gentoo has a lot more entries in this file than we do, since we use mini-Manfiests that only include DIST listings (for distfiles only.) We want to commit our mini-Manifest (still called <tt>Manifest</tt>, just with less entries in it) rather than the one that came from Gentoo.
		+	# Edit the top of each ebuild, and remove all <tt>Copyright</tt> and <tt>$Header:</tt> lines at the top of the file. We have a LICENSE.txt and COPYRIGHT.txt file in the root of our Portage tree, which is easier to maintain than keeping all the years up-to-date in each ebuild. Also, the <tt>$Header:</tt> line is there for the CVS version control system in Gentoo which Funtoo does not use. ''The only comment that should remain on the top of the ebuild is the one stating that it is distributed under the GPLv2.''.
		+
		+	Here are a few additional changes that you are allowed to make to any forked ebuilds:
		+
		+	# Line length greater than 80 characters. Gentoo enforces an 80-character line length limit. We don't.
		+	# <tt>KEYWORDS<tt> of <tt></tt> and <tt>~</tt>. Gentoo does not allow these shortcuts. We do. They allow you to say "all arches" and "all unstable arches" in a concise way. Gentoo doesn't allow these shortcuts because it's Gentoo's policy to have each arch team manually approve each package. We do not have this policy so we can use the shortcuts.
		+	# Use of <tt>4-python</tt> EAPI. We allow the use of this EAPI for enhanced python functionality.

	[[Category:Development]]		[[Category:Development]]

@@ Line 12: / Line 12: @@
 ;http://git.funtoo.org/funtoo-overlay/tree/funtoo/scripts/merge.py: python script that does the heavy lifting of combining Gentoo tree with various overlays, including our flora and funtoo-overlay. When we want to change what overlays we merge, what packages we exclude as a matter of policy (such as stale packages in some overlays), we make changes to this file.
 ; http://git.funtoo.org/funtoo-overlay/tree/funtoo/scripts/merge_utils.py: python module that contains classes and methods that implement the merging functionality.
 [[Category:Development]]

← Older revision		Revision as of 03:56, 21 January 2013
Line 10:		Line 10:

	; http://git.funtoo.org/funtoo-overlay/tree/funtoo/scripts/current-update.sh: cronned script that calls <tt>merge.py</tt>.		; http://git.funtoo.org/funtoo-overlay/tree/funtoo/scripts/current-update.sh: cronned script that calls <tt>merge.py</tt>.
		+	;http://git.funtoo.org/funtoo-overlay/tree/funtoo/scripts/merge.py: python script that does the heavy lifting of combining Gentoo tree with various overlays, including our flora and funtoo-overlay. When we want to change what overlays we merge, what packages we exclude as a matter of policy (such as stale packages in some overlays), we make changes to this file.
		+	; http://git.funtoo.org/funtoo-overlay/tree/funtoo/scripts/merge_utils.py: python module that contains classes and methods that implement the merging functionality.

	[[Category:Development]]		[[Category:Development]]