Difference between revisions of "Funtoo:Metatools/Advanced Usage"

From Funtoo
Jump to navigation Jump to search
(127 intermediate revisions by 4 users not shown)
Line 1: Line 1:
This page documents how to set up a local development environment that will allow full local testing of any of your customizations, bug fixes or improvements to Funtoo Linux. This includes generating your own meta-repo and kits with your custom changes, as well as getting metro set up for unit tests. We recommend that all Funtoo Linux developers who will be submitting ebuild improvements to use set up this environment for local testing of changes. This setup also allows more involved changes to be tested and validated locally, so that your contributions to Funtoo are as production-ready as possible.
{{Subpages|Gitolite Setup}}


== Overview ==
== Overview ==


For our local development setup, we will be using [http://gitolite.com gitolite] on our development workstation. Gitolite will make things quite a bit easier by managing git repositories for us. Think of it as your own private GitHub that has no Web user interface (we modify its settings by pushing to its special {{c|gitolite-admin}} repo) and you'll have a pretty good idea of what gitolite does. We will be using the following systems in these examples:
Funtoo Linux uses "merge scripts" to create its kits and update meta-repo. These scripts work by sourcing ebuilds from various overlays, and combining them using special algorithms to yield the kits you use. A meta-repo is also generated, which points to the specific kits generated that are designed to work together.


* {{c|repohost}} - this system will be running gitolite under the {{c|repos}} user account and will house git repositories for meta-repo and kits.
Before starting, please read and understand the following pages:
* {{c|rzyen}} - in these examples, this will be the primary development workstation, which will be used for editing cloned git code as well as generating custom kits.
* [[Kit-fixups]]
* [[Kit-fixups/FAQ]]


{{Note|When you follow this guide, it is certainly possible to have {{c|repohost}} and {{c|ryzen}} be the same computer.}}
== Different Approaches ==


Once gitolite is set up, we will use use a variety of source repositories from Funtoo Linux to generate our own meta-repo and kits on our main development workstation (in this guide, again, this system will be called {{c|ryzen}}, which we can then test using [[Metro]]. This process is totally automated by the Funtoo Linux [https://github.com/funtoo/merge-scripts merge scripts].
{{c|merge-all-kits}} can be used in a variety of ways. If you are an individual developer, you may want to use {{c|merge-all-kits}} in ''developer mode'', which is its default mode. Developer mode makes it easy to generate a meta-repo and kits that you can test locally.


{{Note|This document assumes you have basic knowledge of {{c|ssh-keygen}} and how to generate public/private SSH key pairs. If you don't know how to to this, see [[Funtoo Containers#Generating SSH Keys|Generating SSH Keys]] for quick steps or [[OpenSSH Key Management, Part 1]] for a more detailed introduction. For this article, you'll probably want to generate a private keys without a passphrase, which is more convenient but a much greater security risk if the private key gets compromised, or one with a passphrase but using [[keychain]] to manage ssh-agent for you.}}
In developer mode, a {{c|meta-repo}} and all automatically-generated kit git repositories are created from scratch. These git repositories will have no remotes, so they will simply exist locally on disk, and they will not have any history shared with the Funtoo project. It you look at the commit history for the kits and meta-repo, you will see that they essentially have no history.


== Gitolite ==
Another way to use {{c|merge-all-kits}} is with {{c|gitolite}} as a remote, which is documented under the [[#Gitolite Setup|Gitolite Setup]] sub-page. Using this configuration, {{c|merge-all-kits}} will write all of its destination git repositories to gitolite. You can then configure other systems to {{c|ego sync}} from gitolite as a source. This can be good in a distributed development environment. This method can also be used to create a meta-repo and kits that ''diverge'' from Funtoo's kit but still connect to its history.


=== Installation ===
Finally, the {{c|merge-all-kits}} script can be run in a production mode, which is very similar to using it with gitolite except that you may be pushing up your destination meta-repo and kits to a public location like GitHub or GitLab.


To set up gitolite on your LAN, first choose a system that will be used to house your meta-repo and kits git repositories. You can do this on the same system you will be using for testing (and even development), or you can set it up on a dedicated system. It's actually fine to set this up anywhere on the Internet, as git will use ssh to access this repository, but for the purposes of this article, we're assuming you're setting it up somewhere on your LAN.  We will refer to this system as '''repohost'''.  
When first starting out with {{c|merge-all-kits}}, you should definitely start with developer mode and see if that meets your needs first.


On this system, perform the following steps as root:
== Getting The Code ==


{{console|body=
You can find the code that does this on code.funtoo.org, housed at [https://code.funtoo.org/bitbucket/projects/CORE/repos/merge-scripts/browse code.funtoo.org]. The script that does all the heavy-lifting is called {{c|merge-all-kits}}. Let's clone it from git, on the machine that will be generating new kits and meta-repo:
# ##i##useradd -m repos
}}
 
The {{c|repos}} user will be a dedicated user account on the system that will have gitolite enabled and will house our git repositories. Now, we are going to {{c|su}} to this new user on '''repohost''' and perform gitolite configuration:


{{console|body=
{{console|body=
# ##i##su repos
$ ##i##git clone https://code.funtoo.org/bitbucket/scm/core/merge-scripts.git
$ ##i##git clone https://github.com/sitaramc/gitolite
$ ##i##install -d ~/bin
}}
 
Now, as the {{c|repos}} user, add the following to the end of your {{c|~/.bashrc}} file:
 
{{file|body=
export PATH=$HOME/bin:$PATH
}}
}}


What we're doing is setting up a {{c|bin}} directory where the {{c|gitolite}} command will be installed, which will be in your path, so that you can use it more easily. With this done, perform the following steps:
You will also want to install the following dependencies so that the code can run:


{{console|body=
{{console|body=
$ ##i##source ~/.bashrc
# ##i##emerge jinja lxml
$ ##i##gitolite/install -ln
}}
}}


Now, your {{c|repos}} account is almost ready to be used for hosting repositories. The way gitolite works is that it is going to basically take over ssh access to the account, so that when you connect via ssh with git, it will perform its own authentication. For this to work, you will need to enable your own "master key" to access gitolite. To do this, you'll want to decide from which account you'll want to administer gitolite itself. I prefer to use my "drobbins" account on my development workstation, so I will copy my ssh public key from {{c|~/.ssh/id_rsa.pub}} to {{c|/var/tmp/drobbins.pub}} on the gitolite system, and then perform the following steps to "prime" gitolite with this admin public key:
== Configuration and Paths ==


{{console|body=
In general, you should run {{c|merge-all-kits}} as a regular user, and this user needs to be a member of the {{c|portage}} group.
$ ##i##gitolite setup -pk /var/tmp/drobbins.pub
}}


Gitolite will now be initialized to recognize the {{c|drobbins}} remote account as an administrator. This is important because we will be performing the rest of gitolite setup over ssh, using this account.
In the user's home directory, create a {{f|~/.merge}} directory with the following contents:
 
{{Note|OK, gitolite is installed on '''repohost'''! From this point forward, we will be using the {{c|drobbins}} (or equivalent) account on your development workstation to configure gitolite remotely.}}
 
=== gitolite-admin Clone ===
 
Now that gitolite is ready, we can do everything else remotely. I am going to use the {{c|drobbins}} account on my development workstation '''ryzen''', and you will use whatever account is associated with the public key you loaded into gitolite. I like storing my development repos in {{c|/var/src}}, so I'll go ahead and clone the gitolite-admin repo to that location so it can live along all my other git repos. Feel free to put this git repo wherever you like to store git repos that you develop on:
 
{{console|body=
$ ##i##cd /var/src
$ ##i##git clone repos@repohost:gitolite-admin
$ ##i##cd gitolite-admin
}}
 
We are now ready to configure gitolite. We'll do this by modifying {{c|conf/gitolite.conf}} in the git repo and adding new ssh public keys to {{c|keydir/}} as needed. You will see that the initial public key you used to "prime" gitolite already exists in {{c|keydir/}}. Once we change the configuration, and potentially add new public ssh keys that we want to grant access to gitolite-managed repositories, we'll perform a {{c|git commit}} and {{c|git push}}, and if gitolite doesn't complain about our changes, they'll take effect immediately. We'll go through our initial configuration steps below.
 
=== gitolite Configuration ===
 
To properly configure gitolite, we are going to need a public key that is associated with the root user of the workstation that is going to be generating meta-repo and kits. The system that I am using to do this is my personal development workstation, named {{c|ryzen}}, so this key is going to be called {{c|ryzen-root.pub}}. Regeneration of kits does benefit greatly from having multiple cores.
 
You will want to copy this key into the {{c|keydir}} directory in the {{c|gitolite-admin}} repo, and add it to git:
 
{{console|body=
$ ##i##scp remote@blah:ryzen-root.pub keydir/
$ ##i##git add keydir/ryzen-root.pub
}}
 
Now, we're ready to edit {{c|conf/gitolite.conf}} so that it looks like this:
 
{{file|name=gitolite.conf|body=
# group = list of .pub keys in keydir:
 
@drobbins = drobbins
@repomgr = rzyen-root
 
# To enable read-only access to your meta-repo and kits, use this along with
# commented-out line under wildrepo. You will need to add box1-root.pub and
# box2-root.pub to keydir/ as well. This is good for boxes that will be testing
# your meta-repo and kits only but should not be able to modify them.
 
#@reporead = box1-root box2-root
 
# repositories:
 
# SPECIAL ADMIN REPO BELOW -- modify with care!
 
repo gitolite-admin
    RW+    =  @drobbins
 
# AUTO-CREATED (wild) REPOS: gitolite will auto-create repos under wildrepo/ for us
# upon initial clone of any path within, if the repo doesn't already exist.
 
repo wildrepo/..*
    C      =  @repomgr
    RW+    =  @repomgr @drobbins
# NOTE: to enable read-only access for certain boxes, uncomment this line:
#  R      =  @reporead
}}
 
== merge-scripts ==
 
=== Overview ===
 
Funtoo Linux uses "merge scripts" to create its kits. These scripts work by sourcing ebuilds from various overlays, and combining them using special algorithms to yield the kits you use. A meta-repo is also generated, which points to the specific kits generated that are designed to work together.
 
=== The Code ===
 
You can find the code that does this on GitHub, housed at https://github.com/funtoo/merge-scripts. The script that does all the heavy-lifting is called {{c|merge-all-kits.py}}. Let's clone it from git, on the machine that will be generating new kits and meta-repo. In our example, this will be as the root user on ryzen:
 
{{console|body=
# ##i##cd /root
# ##i##git clone https://github.com/funtoo/merge-scripts
}}
 
{{Note|While it is possible to use your own custom merge script repository, we recommend starting by using our official merge-scripts repository on GitHub, and progress to using your own fork of merge-scripts only when you need to.}}
 
=== Configuration ===
 
Now that merge-scripts is cloned, we will need to create a {{c|/root/.merge}} configuration file. Use the following file as a starting point:


{{file|name=/root/.merge|body=
{{file|name=/root/.merge|body=
[sources]
[sources]


flora = https://github.com/funtoo/flora
flora = https://code.funtoo.org/bitbucket/scm/co/flora.git
kit-fixups = https://github.com/mygithub_user/kit-fixups
kit-fixups = https://code.funtoo.org/bitbucket/scm/co/flora.git
gentoo-staging = https://github.com/funtoo/gentoo-staging
gentoo-staging = https://code.funtoo.org/bitbucket/scm/auto/gentoo-staging.git
 
[destinations]
 
base_url = repos@repohost:wildrepo/staging


[branches]
[branches]
Line 149: Line 53:
kit-fixups = master
kit-fixups = master
meta-repo = master
meta-repo = master
[work]
merge-scripts = /root/merge-scripts
source = /var/git/source-trees
destination = /var/git/dest-trees
}}
}}


==== Sources Section ====
By default, {{c|merge-all-kits}} will create a {{c|~/repo_tmp}} directory where it will store all of its work. Inside {{f|~/repo_tmp/source-trees}}, source git trees that will be used to generate meta-repo will be cloned. Inside {{f|~/repo_tmp/dest-trees}}, git repositories will be created to write results into. The meta-repo will be stored at {{c|/~repo_temp/dest-trees/meta-repo}}, and in developer mode, the kits will be stored in meta-repo, at {{c|~/repo_tmp/dest-trees/meta-repo/kits}}, so that meta-repo is configured 'ready to use' at it would appear at {{f|/var/git/meta-repo}}. When 'production' mode is specified via the {{c|--prod}} switch, the meta-repo will not have kits stacked inside it but instead the kits will be written directly into {{c|~/repo_tmp/dest-trees}}.
 
Let's walk through this configuration file. The {{c|[sources]}} section defines locations of repositories that the merge scripts will use as sources for creating kits and meta-repo. In the above sample config, we are using the official [[Flora]] repository from Funtoo, and the official gentoo-staging repository used by Funtoo, but we are using our own fork of https://github.com/funtoo/kit-fixups, which will allow us to add new ebuilds that will appear in kits, such as bug fixes to existing ebuilds in kits, as well as security fixes. For a core Funtoo Linux developer, this is a good way to start. If you are more interested in contributing third-party ebuilds, then you may instead choose to create your own fork of https://github.com/funtoo/flora, and use our standard kit-fixups repository. Or, you could choose to create forks of both. The recommended best practice is to use our upstream repos when possible, and fork only those repos you want to customize. This way, you'll ensure that you have the most up-to-date versions of ebuilds in those unforked repos.
 
==== Branches Section ====
 
The {{c|[branches]}} section is used to define the default branches that are used by the merge-scripts. In general, sticking with {{c|master}} is fine, but if you need the flexibility, you can point the merge scripts to a particular feature branch to use instead, for example.
 
==== Work Section ====


The {{c|[work]}} section is used to define paths where the merge-scripts will do their work. {{c|merge-scripts}} should point to the path where you cloned your merge-scripts repository, as {{c|merge-all-kits.py}} will use this location to look for package-set definitions. These are files that define which catpkgs go in which kits. The {{c|source}} and {{c|destination}} settings above are good defaults, and define where the merge-scripts will clone source repositories and destination (written to) repositories, such as kits and meta-repo. These are kept in two separate hierarchies so they don't get mixed up.
A metadata cache will also be created and stored at {{c|~/repo_tmp/metadata-cache}}, and your user must be a member of the {{c|portage}} group for {{c|merge-all-scripts}} to be able to properly generate the metadata cache.


== Generating New Kits ==
== Running Merge-All-Kits ==


With this all configured, you are ready to generate new kits. These kits will be generated as root on your development system, and will be stored on '''repohost'''. Here are the steps you'd perform:
To run {{c|merge-all-kits}}, use it as follows:


{{console|body=
{{console|body=
# ##i##cd /root
$ ##i##path/to/merge-scripts/bin/merge-all-kits 1.4-release
# ##i##python3 merge-all-kits.py push
}}
}}


{{c|merge-all-kits.py}} will proceed to create new kits and meta-repo, and will push them up to repos@repohost:wildrepo/staging/meta-repo, repos@repohost:wildrepo/staging/core-kit, etc. This process can take quite a while but has been optimized to run quickly on multi-core systems.
The script will then run, and it will git clone flora, kit-fixups and gentoo-staging from the URIs in the {{c|~/.merge}} file, and assemble them into a complete meta-repo. The meta-repo will be located at {{f|$HOME/repo_tmp/dest-trees/meta-repo}}.
 
== Using New Kits ==


Now that the new meta-repo and kits are created, here's how you'll use them on an existing Funtoo system, instead of your official Funtoo meta-repo and kits. First, we'll want to modify {{c|/etc/ego.conf}} as follows:
To use the {{c|meta-repo}} for testing, you can add the following lines to {{f|/etc/ego.conf}}:


{{file|name=/etc/ego.conf|body=
{{file|name=/etc/ego.conf|body=
[global]
[global]
meta_repo_path = /home/user/repo_tmp/dest-trees/meta-repo
}}


sync_user = root
Then, using ego 2.8.0 or later, run the following command:
sync_base_url = repos@repohost:wildrepo/staging/{repo}


# You can have whatever [kits] section you want, below...
{{console|body=
# ##i##ego sync --in-place
}}
}}


You will want to make sure that whatever system is connecting to '''repohost''' is permitted by gitolite, and has its {{c|/root/.ssh/id_rsa.pub file}} stored and committed to the gitolite-admin repository's {{c|keydir/}} and is referenced in {{c|conf/gitolite.conf}}. Otherwise, gitolite will not allow this system to connect. Of course, if you are configuring this on the system that's running {{c|merge-all-kits.py}}, it already has RW permissions to these repositories. Otherwise, you will want to make sure that gitolite has the system's keys as part of its {{c|@reporead}} group.
This will ensure that the proper kit branches in your meta-repo are checked out and that all the repos.conf and profiles files in {{c|/etc/portage}} are configured correctly for your repository to be used. Note that no actual "{{c|git pull}}" will be performed -- this is intentional and a special feature of the {{c|--in-place}} option -- because your local git repositories have no remotes to pull from and contain all the information they need to be used.


{{Note|We change the {{c|sync_user}} to {{c|root}} to force {{c|ego sync}} to use {{c|/root/.ssh/id_rsa}} for authentication. By default, {{c|ego sync}} will attempt to use the {{c|portage}} user which does not have a private key installed, and thus will not be able to authenticate with gitolite.}}
You're now ready to use your meta-repo directly:
 
Now, let's move the current meta-repo out of the way -- you can also simply delete the existing meta-repo. And then we'll re-run {{c|ego sync}}:


{{console|body=
{{console|body=
# ##i##cd /var/git
# ##i##emerge foo
# ##i##mv meta-repo meta-repo.official
# ##i##ego sync
}}
}}


Ego will now sync your custom repository. If you type {{c|emerge -auDN @world}}, ego will now be using your custom kits, rather than the official Funtoo ones. This means that you can perform a variety of things you couldn't before. You can now add your own custom ebuilds to your fork of {{c|kit-fixups}}, and {{c|merge-all-kits.py}} will automatically incorporate these changes into your own custom kits. This will allow you to locally test any changes before submitting them as pull requests to Funtoo. You will also be able to maintain your own meta-repo and kits with your own local modifications, and have your systems use these meta-repo/kits instead of the official Funtoo ones.
 
 
[[Category:Official Documentation]]
[[Category:Development]]

Revision as of 00:35, January 22, 2020

Subpages:
Gitolite Setup

Overview

Funtoo Linux uses "merge scripts" to create its kits and update meta-repo. These scripts work by sourcing ebuilds from various overlays, and combining them using special algorithms to yield the kits you use. A meta-repo is also generated, which points to the specific kits generated that are designed to work together.

Before starting, please read and understand the following pages:

Different Approaches

merge-all-kits can be used in a variety of ways. If you are an individual developer, you may want to use merge-all-kits in developer mode, which is its default mode. Developer mode makes it easy to generate a meta-repo and kits that you can test locally.

In developer mode, a meta-repo and all automatically-generated kit git repositories are created from scratch. These git repositories will have no remotes, so they will simply exist locally on disk, and they will not have any history shared with the Funtoo project. It you look at the commit history for the kits and meta-repo, you will see that they essentially have no history.

Another way to use merge-all-kits is with gitolite as a remote, which is documented under the Gitolite Setup sub-page. Using this configuration, merge-all-kits will write all of its destination git repositories to gitolite. You can then configure other systems to ego sync from gitolite as a source. This can be good in a distributed development environment. This method can also be used to create a meta-repo and kits that diverge from Funtoo's kit but still connect to its history.

Finally, the merge-all-kits script can be run in a production mode, which is very similar to using it with gitolite except that you may be pushing up your destination meta-repo and kits to a public location like GitHub or GitLab.

When first starting out with merge-all-kits, you should definitely start with developer mode and see if that meets your needs first.

Getting The Code

You can find the code that does this on code.funtoo.org, housed at code.funtoo.org. The script that does all the heavy-lifting is called merge-all-kits. Let's clone it from git, on the machine that will be generating new kits and meta-repo: 

user $ git clone https://code.funtoo.org/bitbucket/scm/core/merge-scripts.git

You will also want to install the following dependencies so that the code can run: 

root # emerge jinja lxml

Configuration and Paths

In general, you should run merge-all-kits as a regular user, and this user needs to be a member of the portage group.

In the user's home directory, create a ~/.merge directory with the following contents:

   /root/.merge 
[sources]

flora = https://code.funtoo.org/bitbucket/scm/co/flora.git
kit-fixups = https://code.funtoo.org/bitbucket/scm/co/flora.git
gentoo-staging = https://code.funtoo.org/bitbucket/scm/auto/gentoo-staging.git

[branches]

flora = master
kit-fixups = master
meta-repo = master

By default, merge-all-kits will create a ~/repo_tmp directory where it will store all of its work. Inside ~/repo_tmp/source-trees, source git trees that will be used to generate meta-repo will be cloned. Inside ~/repo_tmp/dest-trees, git repositories will be created to write results into. The meta-repo will be stored at /~repo_temp/dest-trees/meta-repo, and in developer mode, the kits will be stored in meta-repo, at ~/repo_tmp/dest-trees/meta-repo/kits, so that meta-repo is configured 'ready to use' at it would appear at /var/git/meta-repo. When 'production' mode is specified via the --prod switch, the meta-repo will not have kits stacked inside it but instead the kits will be written directly into ~/repo_tmp/dest-trees.

A metadata cache will also be created and stored at ~/repo_tmp/metadata-cache, and your user must be a member of the portage group for merge-all-scripts to be able to properly generate the metadata cache.

Running Merge-All-Kits

To run merge-all-kits, use it as follows: 

user $ path/to/merge-scripts/bin/merge-all-kits 1.4-release

The script will then run, and it will git clone flora, kit-fixups and gentoo-staging from the URIs in the ~/.merge file, and assemble them into a complete meta-repo. The meta-repo will be located at $HOME/repo_tmp/dest-trees/meta-repo.

To use the meta-repo for testing, you can add the following lines to /etc/ego.conf:

   /etc/ego.conf 
[global]
meta_repo_path = /home/user/repo_tmp/dest-trees/meta-repo

Then, using ego 2.8.0 or later, run the following command: 

root # ego sync --in-place

This will ensure that the proper kit branches in your meta-repo are checked out and that all the repos.conf and profiles files in /etc/portage are configured correctly for your repository to be used. Note that no actual "git pull" will be performed -- this is intentional and a special feature of the --in-place option -- because your local git repositories have no remotes to pull from and contain all the information they need to be used.

You're now ready to use your meta-repo directly: 

root # emerge foo
Retrieved from "https://www.funtoo.org/index.php?title=Funtoo:Metatools/Advanced_Usage&oldid=30849"