Then re-apply the patch to the new revision ebuild, by copying the epatch line or lines in the previously patched ebuild bar Be sure to keep whatever patch files under the "files" directory are required for the patch, too. You might have to rename them e. Be careful to apply the patch responsibly , because the source file s the patch alters may have changed since the patch was created. If so, you can create a new patch or consult the original patch author if not you.
To inspect the source files involved, both before and after patching, use the "ebuild" utility. The above will unpack source files and tell you where they are. You can inspect them to verify whether the source file s the patch touches have changed between versions. To see what the source files look like after patching, use the same commands as above but replace "unpack" with "prepare".
Also, make sure your newly patched version is the version being picked up by the build system by running "equery which" inside chroot :. Make sure your new ebuild is the one being picked up. Your upgrade with patch is ready for testing now. Return to the testing step of the process above. Some packages make use of eclasses , which are essentially ebuild code factored out into library files shared across multiple packages. If an ebuild file includes an inherit statement, then it uses an eclass.
You don't have to check for this before you upgrade. The upgrade script will attempt to detect when an eclass must be upgraded along with a package upgrade, but if it is unable to you must upgrade the eclass yourself. If you are not sure how to do that please consult with a member of the build team. This is the only exception to the rule that packages in portage-stable should be unedited. Q : I ran the upgrade script multiple times, and the runtime dropped drastically after the first time.
What gives? By default, it creates a clone in a temporary directory and then re-uses it in later runs updating it each time. This explains the runtime symptoms. Messages from the script should say something to this effect, as well. This will have the same runtime benefits if you run more than once. Do this inside your chroot:. Why do I have to specify them?
A: The boards that "matter" vary. The same is true, to a lesser extent, with architectures. You know how you intend to test the package, and you may have plans to test it on specific boards for specific reasons. If you already have a reasonable subset of boards setup, or available to test on, then running on those boards makes sense. A: This script is intended to live within the build environment we have today.
The script is not intended to be a master script with knowledge of build process order. A: This was considered, but discarded in favor of transparency. You need to know that a branch was created because you must amend the commit message, upload it, and especially abandon the branch in the end. If you created the branch in the first place you are more likely to be aware that you need to abandon the branch to return to your previous state.
Q: Why can't the upgrade script create a complete commit message so no amend is needed, then do the upload and abandon steps as well? A: Firstly, only you know what tests you will run to verify the upgrade and those should be mentioned in the commit message.
Q: How do you install a new package that is not currently installed? I get the "The following packages were not found in current overlays but they do exist upstream The Chromium Projects. Search this site. Chromium OS. Something like this:. To ignore commit 1bb64ff - which is a massive commit that simply formatted the code base using black - you can do the following:.
Python and Bash should be the only hard dependencies. Python 3. Portage includes some optional native extensions which can be built in the source tree by running the following command:. The following setup. If the native extensions have not been built, then portage will use ctypes instead. Skip to content. Star View license. For Portage to detect all the packages you once needed that can now be removed, use the emerge -c or --depclean command. We shall get back to that later.
You can also delete a package by running emerge -cv --depclean --verbose. In this case, the package manager will only delete the package if it has no dependencies. If any, those will be displayed. Delete both of the packages, as shown below:.
To ensure that your system is well maintained not to mention the latest security fixes , you need to update it regularly. Since Portage only sees the ebuild files in the local Portage tree and overlay, you need to update them first.
Once the Portage tree has been updated, you can update the whole system by running emerge -u world. In the following example, we also use the -a --ask option, which tells Portage to display the list of packages before proceeding to update and ask the user if they want to continue:. Portage will look for newer versions of the installed applications.
But it will only check up for applications that you installed, and not the dependencies of those. If you want each package to update, add the -D --deep option:. Since security-related updates also apply to packages that were installed as dependencies, it is recommended to run this command from time to time. If you edited USE flags, you may also want to add the -N --newuse option later on. Then Portage will check if this modification requires installing new packages or recompiling existing ones:.
Calculate Linux comes with the cl-update tool, specially designed for easier system update. The utility will update Portage, install the update, and finally remove unused dependencies. To update, run:. Some packages in the Portage Tree do not have any content as such, as they are an alias used to install a set of other packages.
For example, the 'kde' package installs the full KDE environment on your desktop, as a set of KDE packages depend on it.
If you ever want to remove such a package, running emerge --unmerge will not have the desired effect because the packages it depends on will remain in the system.
With Portage, it is possible to remove residual dependencies, but as dependencies change over time, the first thing you need to do is to update the entire system, including the modifications of USE flags. Now run emerge -c or --depclean to remove the remaining dependencies. Once this is completed, you will have to rebuild the applications that were dynamically linked to the remote packages they no longer need.
As already mentioned, Portage is an extremely powerful engine, supporting many features that other software management tools lack. So it becomes more clear, here are a few aspects of Portage, without going into details. With Portage, multiple versions of a package can co-exist on a system. While other package management solutions name packages according to their version e. A package allocates a specific slot for its version.
Multislot packages can co-exist on a system. There are also packages that do the same but differ in implementation. For instance, metalogd, sysklogd and syslog-ng are system logging services. Applications using the system log cannot depend on one particular software, e. Software is found in different branches of the Portage tree. By default, only stable packages are allowed.
Most of the new software is included in the test branch when added, thus underlining that additional testing is needed before the software can be considered as stable. Though ebuild files are shown for such applications, Portage will not update them before they have been marked as stable.
0コメント