Updating Ebuilds

Updating Ebuilds

Updating ebuilds is important. Our forked ebuilds in Funtoo Linux will go stale if they are not updated periodically, so we want to periodically bump them to new versions. Exceptions are gcc, glibc, binutils, linux-headers, python, perl and ruby and possibly a few other "core" ebuilds that we bump a few times a year in a coordinated fashion. But all other ebuilds in our tree need regular updates.

Overview

The basic process is as follows:

1. Create new ebuild
2. Add ebuild masked for testing using profiles/package.mask/funtoo-staging
3. Request testing on the funtoo-dev mailing list
4. Move to Funtoo Linux current
5. Move to Funtoo Linux stable

Be sure to check the history of the ebuild in funtoo by typing "git log ." and "git log -p ." in the ebuild's directory, to get an idea of why we forked it. If you have any questions, check with Daniel on Discord or via email (staff or funtoo-dev ML).

   Important

There is no problem pulling in the current ebuild from Gentoo as long as any existing funtoo changes are applied to the new ebuild.

Steps to determine Funtoo changes

1. diff -uRN matching-gentoo-version funtoo-version
2. Note any differences on the Funtoo side; these should be preserved.
3. Create new funtoo version based on new gentoo version, with Funtoo changes/patches applied.

Note that often times, there are no significant changes on the Gentoo side, so the best course of action is to:

1. cp funtoo-version new-funtoo-version
2. tweak new-funtoo-version as necessary.

The general principle for lightly-Funtoo-modified ebuilds is that we want to apply any necessary or recommended upstream Gentoo changes, within reason, while preserving the Funtoo modifications that have been made.

The general principle for heavily-Funtoo-modified ebuilds is to understand the scope of the Funtoo changes and what Daniel is trying to do with the ebuild. Often times I am removing cruft from overly-complicated ebuilds to make them more maintainable. A lot of times, I have completely rewritten or redesigned ebuilds. In these cases, we want to look at the Gentoo ebuild more for ideas and for new patches that we might want to consider, but not be so hasty to apply them. We want to apply them only if they make sense for our plans for the ebuild.

Steps After Ebuilds Are Updated

If you have updated the ebuild to Funtoo standards, and are comfortable that it is ready for inclusion in Funtoo Linux, then follow these steps. If the ebuild is not ready yet, be sure to follow-through and either hand off the ebuild to someone else or check with Daniel to get your questions answered so it can be completed.

General steps to follow once the ebuild is ready for inclusion in Funtoo:

1. Masking - Mask the ebuild in profiles/package.mask/funtoo-staging - put your masks at the top of the file (reverse chronological order.)
2. Communicate - Post to the funtoo-dev mailing list and forums announcing the new masked ebuilds, noting that they are available for testing.
3. Monitor - Monitor community resources for success or failure reports for testing.
4. If we have sufficient positive replies, and no outstanding issues, move to Funtoo Linux current.
5. After a period of 2-3 days, move to Funtoo Linux stable.

The List

   Important

If you are going to do one of these things, put your name after it so others know :)

Here's a list of ebuilds that need updating:

• dhcpcd-5.2.11 (or later?) [golodhrim] {already in portage and stable newer versions will follow}
• gdisk-0.6.14 [angry_vincent] {already in portage for testing} / [404_Error] {Functional on sparc64, not to be used with system disks due to OpenBoot incompatibilities}
• bash [angry-vincent] {already in portage for testing}
• tar-1.25+ [angry_vincent] (tar-1.24 had problems with device nodes creation, this is fixed in >=tar-1.25, testing with metro builds) / [404_Error] {Remains to be tested on sparc64}
• sandbox-2.5 (needs some testing in metro) [angry-vincent/golodhrim] {testing running/golodhrim testing done, working perfect in metro} / [404_Error] {Remains to be tested on sparc64}
• klibc-1.5.20 (test with uvesafb)
• dev-lang/perl-5.12.2-r6 [404_error] {already in portage for testing, no issues on sparc64 and amd64 at deployment, perl-cleaner passes, remains to be tested in the long term especially with day to day usage}, -r2 suffers of a parallelism issue

Stuff I (drobbins) can handle:

• feedparser-5.0.1
• openvz-sources
• genkernel {QSG written, some parts to be completed}