Changes

Jump to: navigation, search

Creating Your Own Meta-Repo and Kits

113 bytes removed, 2 months ago
GitHub -> code.funtoo.org
=== The Code ===
You can find the code that does this on GitHubcode.funtoo.org, housed at https://code.funtoo.org/bitbucket/projects/CORE/repos/merge-scripts/browse. 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://code.funtoo.org/bitbucket/scm/core/merge-scripts.git
# ##i##git checkout prod
Branch 'prod' set up to track remote branch 'prod' from 'origin'.
Switched to a new branch 'prod'
#
}}
Now, we do have to perform an initial commit to meta-repo to initialize the repo: {{console|body=# ##i##install -d /var/git/dest-trees# ##i##cd /var/git/dest-trees# ##i##git clone repos@repohost:wildrepo/staging/meta-repo.git# ##i##cd meta-repo# ##i##touch README# ##i##git commit -a -m "First commit."# ##i##git push}} {{Note|While it is possible to use your own custom merge script repository, we recommend starting by using our official merge-scripts repository on GitHubcode.funtoo.org, and progress to using your own fork of merge-scripts only when you need to. Typically you can just fork our kit-fixups repo and work from there.}}
=== Configuration ===
==== Sources Section ====
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://githubcode.comfuntoo.org/funtoobitbucket/projects/CORE/repos/kit-fixups/browse 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://githubcode.comfuntoo.org/funtoobitbucket/projects/CO/repos/flora/browse 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 ====
{{console|body=
# ##i##cd /root
# ##i##git clone https://githubcode.comfuntoo.org/bitbucket/scm/funtoocore/metro.git
# ##i##cd metro
# ##i##scripts/autosetup
{{console|body=
# ##i##cd /root
# ##i##git clone https://githubcode.comfuntoo.org/funtoobitbucket/scm/core/ego.git
}}
This way you will have {{c|/root/ego}} directory with {{c|ego}} binary that is then used by metro.
== Changing Repo Definitions ==
Now that you have generated your first meta-repo, let's look at the key file that defines what overlays and repositories are used to create meta-repo, as well as what kit branches exist, and which ones are prime and which are not. You will want to turn your attention to the {{f|kit-fixups/modules/fixups/foundations.py}} file, which [https://githubcode.comfuntoo.org/bitbucket/projects/CORE/funtoorepos/kit-fixups/blob/masterbrowse/modules/fixups/foundations.py can be viewed here on GitHubcode.funtoo.org]]. Let's take a look at various sections of this file:
{{file|name=foundations.py|lang=python|desc=Top of foundations.py file|body=
{{Note|The above two approaches can be used to move catpkgs between kits transparently to the end-user. In the next ego sync, the catpkg will atomically move from one kit to another and no re-emerging will be required, even if the user had emerged the package from the 'old' kit location.}}
; I want to contribute a cool package to Funtoo.: To do this, you will want to open a pull request against [https://githubcode.comfuntoo.org/bitbucket/projects/CO/repos/funtooflora/browse flora]. Flora is used for all 'bonus' community-contributed ebuilds.
; I want to fix a bug in a particular ebuild.: To do this, first find out where the ebuild is coming from. A good way to do this is to type {{c|ls -d /var/git/meta-repo/kits/*/sys-apps/foobar}}, which will show you what kit it is in. Running {{c|emerge -s sys-apps/foobar}} will also display this information. For research purposes, it is often useful to find where the original catpkg was sourced from. You can consult https://ports.funtoo.org/packages.xml which contains a list of all catpkgs and their source repository. After doing some initial research and seeing what's wrong, you might have a fix for the ebuild. Generally, the best way to fix the ebuild is to clone fork [https://githubcode.comfuntoo.org/bitbucket/funtooprojects/CORE/repos/kit-fixups/browse kit-fixups ] and create an appropriate fixup for the ebuild if none exists, and simply improve our fixup if one exists already. Then you can create a GitHub code.funtoo.org pull request, or open a bug on bugs.funtoo.org, or both. Remember that fixup catpkgs will totally replace all upstream ebuilds, so you may need to include multiple versions of the ebuild, even ones that don't need a fix, if they are still needed for certain packages.
{{Note|If you want to fix a bug in an ebuild and you find that the ebuild comes from flora, you will want to fork flora and submit a pull request against flora instead.}}
Bureaucrats, Administrators, wiki-admins, wiki-staff
5,837
edits

Navigation menu