The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.
News:New Ports-2017 tree and Kits
New Ports-2017 tree and Kits
We've moved ahead with ports-2017 and it is now called 'meta-repo', and is officially part of Funtoo Linux! So all references below to 'ports-2017' should be understood to refer to the alpha version of meta-repo. Learn more about meta-repo here: https://github.com/funtoo/meta-repo . Below you can read about the rationale for kits. Just don't go looking or be waiting for ports-2017 -- it's meta-repo now!
Well, we have some announcements at Funtoo! There is now a new ports tree in beta called ports-2017. We are also introducing something new, called 'kits', which was the fruit of our hacker gathering in Lviv, Ukraine. We'll go into more detail below.
'Kits' are logical parts of the Gentoo Portage tree that we have turned into overlays for the purpose of stability and other purposes. In the past, we have used internal auto-generated overlays called 'shards' to help stabilize Funtoo, but our users don't interact with them directly -- they are used by our merge scripts. 'Kits' are the new generation of shards, and they differ in that they are a real overlay that exists on your system. Kits give us better control over the quality and reliability of ebuilds and give our users more flexibility as to whether they want to run reliable packages or bleeding-edge code.
But maybe a personal example would better demonstrate why kits are important. Recently, updates to xorg caused my laptop workstation to become unstable and flaky, impacting my work. We have come to expect some amount of instability sometimes, as new versions of ebuilds are added to Gentoo and Funtoo. However, this instability came at a rather unfortunate time, and it was clear that we needed a system better than shards for stabilizing packages. Kits allow us to set stability levels on logical sets of packages rather than the entire tree as a whole (such as by using funtoo-stable)-- so we can have the latest and greatest version of gimp, for example, but choose to have a very stable xorg. Or if we delve into newer, less-tested packages, we get to put our toe in the water rather than jumping in the deep-end of the pool.
The mantra and vision of kits is as follows: "If my system becomes unstable, I want it to become unstable because I choose to use a more experimental or new set of packages, not just because I applied regular updates via emerge -auDN @world" This is the strategic vision of the effort and what we are striving to deliver. At the same time, we don't want to take away the ability of users to run newer versions of packages if they choose.
Ultimately, this means that we need to maintain a "curated" set of xorg ebuilds that are very stable and that we trust, and that only get improvements that we can trust fix specific stability issues, vulnerabilities and bugs without introducing new code that can potentially make things less stable. And of course we also need to support the ability for Funtoo users to run the latest (and to some) greatest versions of ebuilds if they want. Kits makes this possible -- allowing us to deliver rock-solid stability and bleeding-edge code at the same time. Let's look at how they work. Take a look here:
https://github.com/funtoo/xorg-kit
You will see several branches, but the branches that are important to understand are master and 1.17-prime. The master branch contains the latest version of xorg as imported from Gentoo. It is automatically updated with the latest and greatest stuff from Gentoo. Bleeding-edge users will want to use the master branch to get access to all the latest Gentoo goodies.
In contrast, 1.17-prime is a branch that contains a curated snapshot of xorg 1.17. We have grabbed a snapshot of xorg from Gentoo that we have found particularly stable, and will be adding security backports, bug fixes and feature enhancements -- but without bumping versions of ebuilds. This is equivalent to an 'enterprise grade' version of xorg. If you need to run xorg and just have it work, all the time, and not have it break, you can know that sticking with the 1.17-prime branch will greatly increase your likelihood of this happening. It is what 1.17-prime is designed for. Note the "-prime" extension, which is our way of saying "this is the good stuff" -- the prime cuts of Larry the Cow ;) 1.17-prime's functionality and hardware support should continue to remain constant -- so that if it works well on your laptop, you can have very good confidence that you can reload your laptop using 1.17-prime and it will continue to work well into the future.
In the future, we will launch a curated build of xorg-1.19 and work on getting it to 'prime' stability status. We will also be launching a component of ego that will allow management and selection of kits.
How to Use (BETA)
Users who want to beta-test the new kits functionality and our 1.17-prime branch can do so as follows. Note that this will cause a major downgrade of xorg over the current version of Funtoo so it is highly recommended to test on a new install.
The most important thing to understand about the design of kits is that they are created to function in combination with our new ports-2017 tree. Why? Because the ebuilds in the xorg-kit have been removed from ports-2017. That's right! xorg is no longer in the master Portage tree but now only in the xorg-kit overlay.
You will need to clone the following trees:
For xorg-kit, you will want to check out the 1.17-prime branch. You can keep ports-2017 on the master branch.
Then, you will want to configure your /etc/portage/repos.conf as follows:
/etc/portage/repos.conf/gentoo [DEFAULT]
main-repo = gentoo
[gentoo]
location = /path/to/repo
sync-type = git
sync-uri = git://github.com/funtoo/ports-2017.git
auto-sync = yes
/etc/portage/repos.conf/xorg-kit [xorg-kit]
location = /root/xorg-kit
sync-type = git
sync-uri = git://github.com/funtoo/xorg-kit.git
auto-sync = yes
Once this is set up, they are ready to use. Note that ports-2017 and xorg-kit should be updated in tandem. Using the config above, emerge --sync should update both repos, one after another.
Let us know what you think of kits and we will keep you updated on our progress as we quickly move kits towards prod-ready.