mirrors/flatcar-scripts
1
0
Fork 0
mirror of https://github.com/flatcar/scripts.git synced 2025-08-31 19:31:07 +02:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #608 from ajeddeloh/update-readme

Browse Source 
readme: add section on package removal
This commit is contained in:
Andrew Jeddeloh 2017-11-16 15:16:49 -08:00 committed by GitHub
commit cf92aefd27
1 changed files with 69 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
sdk_container/src/third_party/portage-stable/README.md vendored
View File

@ -1,6 +1,10 @@
# Overview
This overlay contains curated unmodified Gentoo packages that are part
of the Container Linux build and are exact copies of upstream Gentoo packages.
# Updating packages
Use `src/scripts/update_ebuilds` to fetch the latest copy from Gentoo:
cd ~/trunk/src/scripts
@ -18,9 +22,72 @@ If you'd prefer to use a local copy of the portage tree, you can point
Licensing information can be found in the respective files, so consult
them directly. Most ebuilds are licensed under the GPL version 2.
Upstream Gentoo sources: http://sources.gentoo.org/gentoo-x86/
# Removing packages
Be careful when removing packages. The following section offers tips for preventing
breakage, but they are by no means exhaustive. Be especially careful with packages that
might affect `sys-devel/binutils`, `sys-devel/gcc`, `sys-kernel/linux-headers`, and
`sys-libs/glibc` (see `TOOLCHAIN_PKGS` in `scripts/build_library/toolchain_util.sh`).
## git log
`git log <category>/<package>` will show commits that touched that directory. These can give
clues about why a package was included in the first place and where to look to ensure it really
is unused.
## equery d
`equery d -a <package-name>` will tell you what packages depend on `package-name`. It will
also generate a lot of false positives, since it considers all dependencies for all use flags,
even ones we do not use, such as `test`.
## emerge --emptytree
`emerge --pretend --verbose --emptytree <package-name>` _should_ give a list of all the dependencies
for a given package. Use this to test if `board-packages`, `sdk-depends`, and `@system` can still be
emerged after removing an ebuild and package.
Remember to use the `emerge-<arch>-usr` commands to check `board-packages` and `emerge` to check
`sdk-depends`. Use both when checking `@system`.
Furthermore, the SDK bootstrapping process uses a list of packages defined the by SDK profile's packages.build
file. Install `dev-util/catalyst` and run `/usr/lib64/catalyst/targets/stage1/build.py` to get a list of packages
needed for the boostrapping process, then run `emerge --emptytree` on that list.
A package's ebuild must be removed from `portage-stable` _and_ the package must be removed locally. If only the
ebuild is removed, the package will be silently elided in the `emerge --emptytree` dependency list.
To see if there are any packages installed without ebuilds run `eix -tTc`. There are no `eix-<arch>-usr` wrappers, so double
check the packages are also unmerged via the `emerge-<arch>-usr` commands. Make sure to run
`eix-update` before running other `eix` commands.
`emerge --emptytree` also has unintuitive behavior when handling virtual packages.
When making changes affecting virtual packages (removing a provider, changing use flags that affect
a provider or virtual, etc), `emerge --emptytree` will always prefer an already installed
provider (unless it is masked or otherwise disabled), so unmerge the current provider before
running `emerge --emptytree` to ensure the virtuals are resolved correctly. Look at the virtual package's
ebuild to see what providers it has and use `emerge --search` to see what is the currently installed provider.
See [this bug](https://bugs.gentoo.org/127956).
## grep, git grep, repo grep, ripgrep, find, etc
Use your favorite grep variant to see if the package is used anywhere. Good places to double check are
coreos-overlay, manifest, scripts, and portage-stable, as well as anything specific to the package.
Be sure to check `coreos-overlay` to ensure there are no use flags, accept_keywords, or other leftover bits
relating to the package being removed.
## Updating the metadata cache
If you remove a package, make sure to delete the corresponding files in
metadata/md5cache, or run use egencache to do it for you:
```
egencache --update --repo portage-stable
```
There is also `scripts/update_metadata` which will update both `portage-stable` and `coreos-overlay`
and optionally generate a commit message.
egencache --update portage-stable
## Testing changes
Upstream Gentoo sources: http://sources.gentoo.org/gentoo-x86/
If you have Jenkins running with [this configuration](https://github.com/coreos/jenkins-os), you can make pull requests with your changes and
test them according to the instructions in the [jenkins-os README](https://github.com/coreos/jenkins-os#usage-examples)