On 07/09/2014 09:38 AM, James wrote: > Hello, > > I use the stable portage tree for most everything. > I use and test quite a few overlays. > Both of these are great. > > But now, I'm hacking a small collection my own ebuilds that focus > on some specific needs and science, which I shall refer to collectively as > local ebuilds. I'm curious how other folks would suggest to keep them > separate from the main portage tree and the overlays, but easily > maintainable on my own workstation. >
Create your own overlay. There isn't much to it, you just create a directory somewhere and start filling it with ebuilds. To tell portage about it, add the directory to PORTDIR_OVERLAY. Every overlay should have two files, profiles/repo_name which contains only the name of the repo, and metadata/layout.conf which contains something like, repo-name = your-overlay masters = gentoo eapis-deprecated = 0 1 2 3 4 (The profiles/repo_name file is being phased out IIRC, but stable portage will still complain if it's missing.) When you add ebuilds, place them under category/package-name just like they would appear in $PORTDIR. For bonus points, you can publish your overlay on e.g. github to get a better feel for what it's like committing to the tree. When you modify an ebuild, you should be running `repoman manifest` to generate the new manifest -- otherwise you won't be able to emerge it. After that, you should run `repoman full` to check for problems (e.g. typos, bad dependencies). Finally, if you're using a VCS, `repoman commit` to commit your changes. Those are essentially the steps used to commit to the main tree. You can even tell portage to sign Manifests using your GPG key: http://devmanual.gentoo.org/general-concepts/manifest/ The VCS/signing are optional, but give you a better feel for how things are really done. The knowledge you'll gain from running your own overlay is useful when you're contributing to other people's overlays, or even when filing bugs.
