Difference between pages "Install/de/Partitioning" and "Forking An Ebuild"

< Install(Difference between pages)
 
m
 
Line 1: Line 1:
<noinclude>
+
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.
{{InstallPart|the process of partitioning and filesystem creation}}
+
</noinclude>
+
===Vorbereiten der Festplatte ===
+
  
Diese Sektion handelt über die verschiedenen Möglichkeiten Funtoo Linux auf einer Festplatte zu installieren und zu booten.
+
== Portage Tree Generation ==
  
==== Einleitung ====
+
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 [https://github.com/funtoo/funtoo-overlay Funtoo-overlay]. Some packages added are brand new, while other packages are our special forked versions that replace existing packages.
  
Früher gab es nur eine Variante einen PC zu booten, alle Desktop- und Servercomputer hatten einen voreingestellten PC  BIOS, alle Festplatten nutzten den Master Boot Record (MBR) um das System zu booten und unsere Festplatten waren  mit dem MBR Partitionsschema in verschiedene Regionen partitioniert. Das war einfach wie's gemacht wurde. Und uns gefiel es!
+
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.
  
Dann kamen EFI und UEFI, neue firmware designt das System zu booten, gemeinsam mit GTP Partitionstabellen um Partitionen auf Festplatten größer als 2.2TB zu definieren.
+
If you're interested in seeing the actual script that does all these things, take a look at the following files:
Plötzlich haben wir eine breite Wahl von Optionen, Linux Systeme zu installieren und zu booten. Damit haben wir nun eine komplexere Situation als damals.
+
  
Nehmen wir einen Moment um die verfügbaren Optionen, zur Konfiguration der Festplatte um Linux zu booten, zu besprechen.
+
; http://git.funtoo.org/funtoo-overlay/tree/funtoo/scripts/current-update.sh: cronned script that calls <tt>merge.py</tt>.
Diese Installationsanleitung nutzt und empfiehlt die old-school Methode des BIOS bootens mit hilfe des MBR. Es funktioniert und (außer in seltenen Fällen) ist universal unterstützt.
+
;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.
Mit dieser Methode ist nichts falsch, solange deine Systemfestplatte nur bis zu 2TB groß ist. Solange wird diese Methode die volle Kapazität deiner Festplatte nutzen.  
+
; http://git.funtoo.org/funtoo-overlay/tree/funtoo/scripts/merge_utils.py: python module that contains classes and methods that implement the merging functionality.
  
Es gibt aber einige Situationen, in denen diese old-school Methode nicht optimal ist. Falls du eine Systemfestplatte >2TB hast, dann erlauben dir MBR Partitionen keinen Zugang zum gesamten Speicher.
+
== Forking an Ebuild ==
Das ist also ein Grund gegen diese Methode. Ein Weiterer ist, dass es "PC" Systeme gibt, welche das booten via BIOS nicht mehr unterstützen und dich zwingen via UEFI zu booten.
+
Aus Mitleid für die PC-Nutzer, die in diese Zwickmühle geraten, decken wir das Booten via UEFI zusätzlich in dieser Installationsanleitung ab .
+
  
Unsere empfehlung ist immer noch die old-school Methode, es seiden du hast Gründe dagegen.
+
In general, we fork ebuilds from Gentoo that we want to modify in some way. Before you fork an ebuild, it's important to understand that in general we fork entire packages, not just a single ebuild. This means that if you want to make some changes to <tt>sys-foo/bar</tt>, you are going to fork all <tt>sys-foo/bar</tt> ebuilds, and then Funtoo will be responsible for continuing to maintain these ebuilds until the package is unforked. Here are the steps we would use to fork <tt>sys-foo/bar</tt>:
Der Bootloader, den wir nutzen um den Linux Kernel zu laden, heißt GRUB. Also nennen wir die Methode  '''BIOS + GRUB(MBR) ''' Methode.
+
Es ist die traditionelle Methode um ein Linux System bootbar zu machen.
+
 
+
Falls du via UEFI booten willst, empfehlen wir dir nicht den MBR zum booten zu nutzen, was nur manche Systeme unterstützen, sondern wir empfehlen UEFI zu nutzen um GRUB zu laden.
+
GRUB wird dann das Linux System booten. Wir referenzieren zu dieser Methode mit '''UEFI + GRUB (GPT)'''.
+
 
+
Und ja, es gibt noch weitere Methoden, von denen einige auf der [[Boot Methods]] Seite dokumentiert sind.
+
Unsere Empfehlung war immer die  '''BIOS + GRUB (GPT)'' Methode, welche allerdings nun nicht mehr konsistent und hardwareübergreifend unterstützt wird.
+
 
+
'''Die größte Frage ist immer -- Welche Bootmethode sollst du nutzen?''' Hier ist mein Gedankengang.
+
 
+
;Grundsatz 1 - Old School: Falls du verlässlich via System Rescue CD booten kannst und dir ein leicht blaues Menü angezeigt wird, dann bootet die CD via BIOS und es ist sehr wahrscheinlich, das du auch Funtoo Linux via BIOS booten kannst. Also gehe old-school und nutze diese Methode, es sei denn du hast Gründe via UEFI zu booten. Zum Beispiel eine Systemfestplatte >2.2TB  In diesem Fall beachte Grundsatz 2, wenn dein System UEFI unterstützt.
+
 
+
;Grundsatz 2 - New School: Falls du verlässlich via System Rescue CD booten kannst und dir ein schwarz und weißes Menü, --Glückwunsch, dein System ist konfiguriert UEFI zu unterstützen. Das bedeutet das du bereit bist Funtoo Linux einzurichten um via UEFI zu booten. Dein System könnte immer noch das Booten übers BIOS unterstützen, aber versuch es einfach mal mit UEFI als erstes. Du kannst in deiner BIOS Konfiguration herum stochern und damit spielen.
+
 
+
;Was ist der große Unterschied zwischen Old School und New School?: Hier ist der Deal. Falls du mit old-school MBR Partitionen gehst, deine <code>/boot</code> Partition wird ein ext2 Dateisystem haben, und du wirst <code>fdisk</code>nutzen um MBR Partitionen zu erstellen. Fallse du mit new-school GPT Partitionen und booten via UEFI gehst, wird deine <code>/boot</code> Partition ein  vfat Dateisystem haben, da UEFI dies lesen kann,außerdem wirst du <code>gdisk</code> nutzen um GPT Partitionen zu erstellen. Und du wirst GRUB ein wenig anders installieren. Das ist alles was es zu wissen gibt, für den Fall das du neugierig warst.
+
 
+
;Notiere auch: Um Funtoo Linux via new-school UEFI Methode bootbar zu machen ist es notwendig, dass die System Rescue CD via UEFI gebooted wurde -- und du den ursprünglichen schwarz und weißen Bildschirm siehst. Ansonsten wird UEFI nicht aktiv sein und du wirst nicht in der Lage sein Funtoo Linux korrekt zu installieren.
+
 
+
{{Note|'''Einige Motherboards unterstützen UEFI nicht richtig.''' Informiere dich. Zum Beispiel, das Award BIOS in meinem Gigabyte GA-990FXA-UD7 rev 1.1 hat eine Option das Booten via UEFI für CD/DVD zu aktivieren. '''Das ist aber nicht ausreichend um UEFI für Festplatten zu nutzen und Funtoo Linux zu installieren.''' UEFI muss für entfernbare Datenträger und fixierte Datenträger unterstützt werden. (Damit du deine neue Funtoo Installation booten kannst) Tatsächlich haben die neueren Revisionen des Boards(rev 3.0) volle UEFI unterstützung. Das könnte der dritte Grundsatze sein -- kenne die Hardware. }}
+
 
+
==== Old-School (BIOS/MBR) Methode ====
+
 
+
{{Note|Falls du via System Rescue CD booten kannst und dir ein leicht blaues Menü angezeigt wird nutze diese Methode. Falls du die new-school Methode nutzen wirst, [[#New-School (UEFI/GPT) Methode|Klicke hier um direkt zu UEFI/GPT zu springen.]]}}
+
 
+
===== Vorbereitung  =====
+
 
+
Erstens, es ist ein gute Idee sicherzustellen, dass du die richtige Festplatte zum Partitionieren gefunden hast. Versuche es mit diesem Befehl und verifiziere, dass  <code>/dev/sda</code> die Festplatte zum Partitionieren ist:
+
  
 +
# Find <tt>sys-foo/bar</tt> in you regular Portage tree. Make sure you have run <tt>emerge --sync</tt> recently to ensure it is up-to-date. If you want to fork from very recent changes that are not yet in our tree, you may need to grab the most recent Gentoo Portage tree to serve as your source for <tt>sys-foo/bar</tt> (this typically isn't necessary.)
 
<console>
 
<console>
# ##i##fdisk -l /dev/sda
+
# alias to recursively grab latest from Gentoo Portage tree WITHOUT history
 
+
# usage: getgen gentoo-x86/dev-db/mongodb
Disk /dev/sda: 640.1 GB, 640135028736 bytes, 1250263728 sectors
+
alias getgen="cvs -d :pserver:anonymous@anoncvs.gentoo.org:/var/cvsroot export -D$(date '+%Y-%m-%d')"
Units = sectors of 1 * 512 = 512 bytes
+
Sector size (logical/physical): 512 bytes / 512 bytes
+
I/O size (minimum/optimal): 512 bytes / 512 bytes
+
Disk label type: gpt
+
 
+
 
+
#        Start          End    Size  Type            Name
+
1        2048  1250263694  596.2G  Linux filesyste Linux filesystem
+
 
</console>
 
</console>
 +
# Copy the <tt>sys-foo/bar</tt> directory in its entirety to <tt>funtoo-overlay/sys-foo/bar</tt>.
 +
# Make any necessary modifications to <tt>funtoo-overlay/sys-foo/bar</tt>.
 +
# Perform some funtoo-ification steps prior to commit.
 +
# Add and commit the changes to funtoo-overlay.
 +
# Push changes to funtoo-overlay.
  
Nun, ist es empfohlen, das du alle existierende MBR oder GTP Partitionstabellen auf der Festplatte, welche das System beim Booten verwirren könnten löschst. Wir machen dies mit <code>sgdisk</code>:
+
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.
{{fancywarning|Dies wird deine existierende Partitionen unerreichbar machen! Du bist "stark" gewarnt und  geraten alle wichtigen/kritischen Daten vorher zu sichern.}}
+
  
<console>
+
== Funtoo-ification ==
# ##i##sgdisk --zap-all /dev/sda
+
  
Creating new GPT entries.
+
When we fork a package from Gentoo, we perform the following tweaks to the package directory before committing:
GPT data structures destroyed! You may now partition the disk using fdisk or
+
other utilities.
+
</console>
+
  
Diese Ausgabe ist nichts beängstigendes, da der Befehl trotzdem erfolgreich war:
+
# 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.''.
  
 
<console>
 
<console>
***************************************************************
+
# If you find yourself doing this often, place this function in your .bashrc, .zshrc, etc
Found invalid GPT and valid MBR; converting MBR to GPT format
+
funtooize() {
in memory.  
+
    if [ -z "$1" ]; then
***************************************************************
+
        search_path='.'
</console>
+
    else
 +
        search_path=$1
 +
    fi
  
===== Partitionierung =====
+
    find $search_path -type f -exec sed -i -e '/^# Copyright\|^# \$Header/d' {} +
 
+
    find $search_path -type f -name "ChangeLog*" -delete
Nun werden wir  <code>fdisk</code> nutzen um die MBR Partitionstabelle und die Partitionen zu erstellen:
+
    find $search_path -type f -name '*.ebuild' -exec ebuild {} manifest \;
 
+
}
<console>
+
# ##i##fdisk /dev/sda
+
 
</console>
 
</console>
  
Innerhalb <code>fdisk</code>, folge diesen Schritten:
+
Here are a few additional changes that you are allowed to make to any forked ebuilds:
  
'''Leere die Partitionstabelle''':
+
# 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.
  
<console>
+
[[Category:Development]]
Command (m for help): ##i##o ↵
+
</console>
+
 
+
'''Erstelle Partition 1''' (boot):
+
 
+
<console>
+
Command (m for help): ##i##n ↵
+
Partition type (default p): ##i##↵
+
Partition number (1-4, default 1): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##+128M ↵
+
</console>
+
 
+
'''Erstelle Partition 2''' (swap):
+
 
+
<console>
+
Command (m for help): ##i##n ↵
+
Partition type (default p): ##i##↵
+
Partition number (2-4, default 2): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##+2G ↵
+
Command (m for help): ##i##t ↵
+
Partition number (1,2, default 2): ##i## ↵
+
Hex code (type L to list all codes): ##i##82 ↵
+
</console>
+
 
+
'''Erstelle root Partition:'''
+
 
+
<console>
+
Command (m for help): ##i##n ↵
+
Partition type (default p): ##i##↵
+
Partition number (3,4, default 3): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##↵
+
</console>
+
 
+
'''Verifiziere die Partitionstabelle:'''
+
 
+
<console>
+
Command (m for help): ##i##p
+
 
+
Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors
+
Units: sectors of 1 * 512 = 512 bytes
+
Sector size (logical/physical): 512 bytes / 512 bytes
+
I/O size (minimum/optimal): 512 bytes / 512 bytes
+
Disklabel type: dos
+
Disk identifier: 0x82abc9a6
+
 
+
Device    Boot    Start      End    Blocks  Id System
+
/dev/sda1          2048    264191    131072  83 Linux
+
/dev/sda2        264192  4458495  2097152  82 Linux swap / Solaris
+
/dev/sda3        4458496 625142447 310341976  83 Linux
+
</console>
+
 
+
'''Schreibe die Partitionstabelle auf die Festplatte:'''
+
 
+
<console>
+
Command (m for help): ##i##w
+
</console>
+
 
+
Deine neue MBR Partitionstabelle wird nun auf die Systemfestplatte geschrieben.
+
 
+
{{Note|Du bist noch nicht fertig mit der Partitionierung! Jetzt, springe zu [[#Creating filesystems|Creating filesystems]].}}
+
 
+
==== New-School (UEFI/GPT) Methode ====
+
 
+
{{Note|Falls du verlässlich via System Rescue CD booten kannst und dir ein schwarz und weißes Menü angezeigt wurde, verwende diese Methode. Ansonsten diese Methode wird nicht funktionieren!}}
+
 
+
Die <tt>gdisk</tt>Befehle um GTP Partitionstabellen zu erstellen lauten wie folgt. Passe die Große jeweils an, falls notwendig, diese Voreinstellungen werden für die meisten Nutzer funktionieren.Beginne <code>gdisk</code>:
+
 
+
<console>
+
# ##i##gdisk /dev/sda
+
</console>
+
 
+
Innerhalb <tt>gdisk</tt>, folge diesen Schritten:
+
 
+
'''Erstelle eine neue leere Partitionstabelle''' (Dies wird alle Daten löschen!):
+
 
+
<console>
+
Command: ##i##o ↵
+
This option deletes all partitions and creates a new protective MBR.
+
Proceed? (Y/N): ##i##y ↵
+
</console>
+
 
+
'''Erstelle Partition 1''' (boot):
+
 
+
<console>
+
Command: ##i##n ↵
+
Partition Number: ##i##1 ↵
+
First sector: ##i##↵
+
Last sector: ##i##+500M ↵
+
Hex Code: ##i##↵
+
</console>
+
 
+
''Erstelle Partition 2''' (swap):
+
 
+
<console>
+
Command: ##i##n ↵
+
Partition Number: ##i##2 ↵
+
First sector: ##i##↵
+
Last sector: ##i##+4G ↵
+
Hex Code: ##i##8200 ↵
+
</console>
+
 
+
'''Erstelle Partition 3''' (root):
+
 
+
<console>
+
Command: ##i##n ↵
+
Partition Number: ##i##3 ↵
+
First sector: ##i##↵
+
Last sector: ##i##↵##!i## (for rest of disk)
+
Hex Code: ##i##↵
+
</console>
+
 
+
Während des Prozesses kannst du mit "<tt>p</tt>" und Enter die aktuelle Partitionstabelle anschauen. Falls du einen Fehler machst "<tt>d</tt>" eine existierende Partition löschen.
+
Wenn du fertig bist mit deiner Partitionierung kannst du mit "<tt>w</tt>" die Konfiguration auf die Festplatte schreiben lassen.
+
 
+
'''Schreibe Partitionstabelle auf die Festplatte''':
+
 
+
<console>
+
Command: ##i##w ↵
+
Do you want to proceed? (Y/N): ##i##Y ↵
+
</console>
+
 
+
Die Partitionstabelle wird nun auf die Festplatte geschrieben und <tt>gdisk</tt> wird beendet.
+
 
+
Nun, wurden deine GTP/GUID Partitionen erstellt und sie werden gezeigt wie folgt under ''block devices'' unter Linux:
+
 
+
 
+
* <tt>/dev/sda1</tt>, wird für das <tt>/boot</tt> Dateisystem genutzt,
+
* <tt>/dev/sda2</tt>, wird für den swap Speicher genutzt, und
+
* <tt>/dev/sda3</tt>, wird für das root Dateisystem verwendet.
+
 
+
==== Erstelle Dateisysteme ====
+
 
+
{{Note|Dieser Abschnitt behandelt BIOS ''und'' UEFI Installationen. Nicht Überspringen!}}
+
 
+
Bevor du die neuen Partitionen nutzen kannst, müssen die Partitionen mit Dateisystem ''metadata'' initialisiert werden.
+
Dieser Prozess ist bekannt als "Erstellen des Dateisystems".
+
Nachdem die Dateisysteme erstellt wurden kann die Festplatte eingebunden werden und Daten speichern.
+
 
+
Lass es uns simple halten. Nutzt du old-school MBR Partitionen? Falls ja, erstellen wir ein ext2 Dateisystem unter /dev/sda1:
+
 
+
<console>
+
# ##i##mkfs.ext2 /dev/sda1
+
</console>
+
 
+
Falls du new-school GPT Partitionen für UEFI nutzt, erstellst du ein vfat Dateisystem unter /dev/sda1, da UEFI dieses lesen kann:
+
 
+
 
+
<console>
+
# ##i##mkfs.vfat -F 32 /dev/sda1
+
</console>
+
 
+
Nun, lass uns eine swap Partition erstellen. Die Partition wird genutzt als Überlauf (virtueller Zwischenspeicher) , wenn dein RAM ausgelastet ist oder wenn du dein System in den Ruhezustand versetzen willst.
+
 
+
Du wirst kein Dateisystem auf der swap Partition erstellen, denn swap wird nicht zum Speichern von Datein genutzt, aber es ist notwendig eine swap Partition zu initialisieren via dem  <code>mkswap</code> Befehl. Dann werden wir den Befehl <code>swapon</code> ausführen, damit ist die swap Partition sofort aktiv innerhalb deiner aktuellem (live CD) Umgebung.
+
Für den Fall das der swap im späterem Installationsprozess benötigt wird:
+
<console>
+
# ##i##mkswap /dev/sda2
+
# ##i##swapon /dev/sda2
+
</console>
+
 
+
Nun, müssen wir das root Dateisystem erstellen. Dort wird das Wurzelverzeichnis von Funtoo Linux leben.
+
Wir empfehlen im allgemeinen ext4 oder XFS als root Dateisystem. Bist du nicht sicher wähle ext4.
+
Hier steht wie man ein ext4 root Dateisystem erstellt:
+
 
+
<console>
+
# ##i##mkfs.ext4 /dev/sda3
+
</console>
+
 
+
...und hier steht wie du ein XFS root Dateisystem erstellen kannst, falls du XFS wählst:
+
 
+
<console>
+
# ##i##mkfs.xfs /dev/sda3
+
</console>
+
 
+
Deine Dateisysteme (und swap) wurden nun initialisiert, so dass sie nun eingehängt werden können (angehängt an deine existierende Verzeichnisstruktur) und zum Speichern genutzt werden können. Jetzt sind wir fertig um mit der Funtoo Linux Installation zu beginnen, auf unseren brand neuen Dateisystemen.
+
 
+
{{fancywarning|1=
+
Wenn du mit einen OpenVZ Host arbeitest, nutze bitte nur ext4. Das Parallels Entwicklerteam testet ausschließlich mit ext4 und moderne Versionen des  <code>openvz-rhel6-stable</code> sind '''nicht''' kompatible mit XFS. Es könnten Kernel Bugs auftreten.
+
}}
+
 
+
==== Einhängen der Dateisystemen ====
+
Hänge die neuen Dateisysteme wie folgt ein, erstelle <code>/mnt/funtoo</code> als Einhängepunkt zur Installation:
+
 
+
<console>
+
# ##i##mkdir /mnt/funtoo
+
# ##i##mount /dev/sda3 /mnt/funtoo
+
# ##i##mkdir /mnt/funtoo/boot
+
# ##i##mount /dev/sda1 /mnt/funtoo/boot
+
</console>
+
Optional, falls du  separate Dateisysteme für  <code>/home</code> oder alle andere erstellt hast:
+
 
+
<console>
+
# ##i##mkdir /mnt/funtoo/home
+
# ##i##mount /dev/sda4 /mnt/funtoo/home
+
</console>
+
 
+
Falls du eine separate Partition für <code>/tmp</code> oder <code>/var/tmp</code> auf einem anderem Dateisystem hast, stelle sicher, dass die Zugriffsrechte des  Einhängepunkt stimmen und er global beschreibbar ist, wie folgt:
+
 
+
<console>
+
# ##i##chmod 1777 /mnt/funtoo/tmp
+
</console>
+

Latest revision as of 05:25, May 30, 2015

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

If you're interested in seeing the actual script that does all these things, take a look at the following files:

http://git.funtoo.org/funtoo-overlay/tree/funtoo/scripts/current-update.sh
cronned script that calls merge.py.
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.

Forking an Ebuild

In general, we fork ebuilds from Gentoo that we want to modify in some way. Before you fork an ebuild, it's important to understand that in general we fork entire packages, not just a single ebuild. This means that if you want to make some changes to sys-foo/bar, you are going to fork all sys-foo/bar ebuilds, and then Funtoo will be responsible for continuing to maintain these ebuilds until the package is unforked. Here are the steps we would use to fork sys-foo/bar:

  1. Find sys-foo/bar in you regular Portage tree. Make sure you have run emerge --sync recently to ensure it is up-to-date. If you want to fork from very recent changes that are not yet in our tree, you may need to grab the most recent Gentoo Portage tree to serve as your source for sys-foo/bar (this typically isn't necessary.)
# alias to recursively grab latest from Gentoo Portage tree WITHOUT history
# usage: getgen gentoo-x86/dev-db/mongodb
alias getgen="cvs -d :pserver:anonymous@anoncvs.gentoo.org:/var/cvsroot export -D$(date '+%Y-%m-%d')"
  1. Copy the sys-foo/bar directory in its entirety to funtoo-overlay/sys-foo/bar.
  2. Make any necessary modifications to funtoo-overlay/sys-foo/bar.
  3. Perform some funtoo-ification steps prior to commit.
  4. Add and commit the changes to funtoo-overlay.
  5. Push changes to funtoo-overlay.

At this point, the forked sys-foo/bar package will be part of funtoo-overlay. The next time our unified Portage tree is generated by merge.py (the one that users have in their /usr/portage and is updated via emerge --sync), your forked ebuild will be used in place of the Gentoo ebuild. Why is this? It is because our merge.py 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 sys-foo/bar directory will be used in place of Gentoo's sys-foo/bar 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:

  1. Removal of ChangeLog.
  2. Run ebuild foo-1.0.ebuild digest before committing. This will cause the Manifest 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 Manifest, just with less entries in it) rather than the one that came from Gentoo.
  3. Edit the top of each ebuild, and remove all Copyright and $Header: 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 $Header: 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..
# If you find yourself doing this often, place this function in your .bashrc, .zshrc, etc
funtooize() {
    if [ -z "$1" ]; then
        search_path='.'
    else
        search_path=$1
    fi

    find $search_path -type f -exec sed -i -e '/^# Copyright\|^# \$Header/d' {} +
    find $search_path -type f -name "ChangeLog*" -delete
    find $search_path -type f -name '*.ebuild' -exec ebuild {} manifest \;
}

Here are a few additional changes that you are allowed to make to any forked ebuilds:

  1. Line length greater than 80 characters. Gentoo enforces an 80-character line length limit. We don't.
  2. KEYWORDS of * and ~*. 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.
  3. Use of 4-python EAPI. We allow the use of this EAPI for enhanced python functionality.