MaintenanceThe basicsTweaking your installuse FEATURES=buildpkg to keep backups of all emerged packages so you can rollback in case of problems.
- you can also use this to build binary packages for multiple machines
Cleaning out logfilesGetting portage messages for an emergeUse update
- by default does our system update procedure:
emerge -uDN @world --with-bdeps y
(with --pretend first, to review the list: recommended procedure)
- review and edit USE flags on a per-package basis, or globally, by pressing E for the edit list dialog.
- followed by:
glsa-checkdepclean@preserved-rebuild (if required)
revdep-rebuild
- to get the same with --changed-use use: update -auDU

To run: emerge -uD --changed-use @world without bdeps, use: update -auDU @world
..and take out the a if you just want to run it without confirming. It supports parallel builds.

Full procedure without bdeps: update -auDN --bdeps=n

IOW: if you give it a parameter like a pkg-name, it just wraps emerge. If not, it does a system upgrade.
except: you have to tell it to install a package to world with -i, eg: update -ia kate
By default it just updates the package, ie: emerge -1 package which pulls in needed dependencies, with your flags.

How to use dep? (The man page is hard when you're tired) Top 3 thanks to mark_alec on IRC
dep -w, --pruneworld
dep -u, --usedesc for PKG
dep -e, --versions and status of PKG
-t, --tree-depends and -T, --reverse-tree of PKG
-U, --iuse list pkgs which declare a USE flag
- kudos to ecatmur for the script.

mount -t smbfs -o lfs allows large files (IRC)

For archive: no name, took it down a while ago, sorry:
Let's assume you want to write /usr/local into a file under /mnt/archive:
find /usr/local -print | cpio -H tar -ov | bzip2 > /mnt/archive/usr_local.tar.bz2
To list the contents of your archive:
bunzip2 -c /mnt/archive/usr_local.tar.bz2 | cpio -itv
To extract the archive, you can use:
bunzip2 -c /mnt/archive/usr_local.tar.bz2 | cpio -imdv
Now, let's assume your /usr/local/ contains the file /usr/local/bin/myscript. You can extract just this file by:
bunzip2 -c /mnt/archive/usr_local.tar.bz2 | cpio -imdv /usr/local/bin/myscript
or even extract all of your scripts that start with "my":
bunzip2 -c /mnt/archive/usr_local.tar.bz2 | cpio -imdv '/usr/local/bin/my*'Note the quotes on the pattern so the shell doesn't interpret it.

AFAIR, there are some older versions of cpio, in which the -H tar didn't preserve the modification time correctly.
I usually prefer option -c or -H crc, which are, however, not compatible with tar.
cpio has many other interesting options, so it's worth having a look at the manpage.

Adding patches to an ebuild:
First try to see if the ebuild supports epatch_user already: if it inherits from eutils (perhaps indirectly) then it will.
Support for apply_user_patches has been proposed for EAPI 6.

You can also use the post_src_unpack() user hook and the profile.bashrc in the
base profile for this. E.g.:

uberpinguin:
you need to edit the ebuild and use 'epatch' to apply the patch. once you've got the ebuild tweaked, you'll have to 'ebuild EBUILD digest' to fix the checksums. I'd recommend creating an overlay to put your modded ebuild in, though.
read the man page for patch and look at the first couple lines of the patch to see what '-p' level to use; apply the patch; ebuild EBUILD digest to fix the checksums; try emerging it

Having device nodes for stuff udev doesn't handle:
<Kyuu> ..a tarballed udev tree which can be set in /etc/conf.d/rc
<MvG> RC_DEVICE_TARBALL="yes"
from rc file:
# Set to "yes" if you want to save /dev to a tarball on shutdown
# and restore it on startup. This is useful if you have a lot of
# custom device nodes that udev does not handle/know about.
<MvG> You create the device node manually, and next time you reboot it's recreated from the tarball.

Note this is now the default method in portage (and has been for a few years.)

This is an excellent tip from zmedico for speeding up portage cache updates- by not doing them! Seems the metadata kept in /var/cache/edb is pretty similar to the metadata which is rsynced (slightly different format) and portage can be set just to use the rsynced version. Perfect!

and set FEATURES="-metadata-transfer" in make.conf. You also need to delete the /var/cache/edb/dep/usr/portage directory recursively. (I tarred mine up cos i was scared :)

man portage wrote:

modules
This file can be used to override the metadata cache implementation. In practice, portdbapi.auxdbmodule is the only variable that the user will want to override.
Example:
portdbapi.auxdbmodule = cache.metadata_overlay.database
The metadata_overlay cache module makes it possible to disable FEATURES="metadata-transfer" in make.conf(5). When the user initially enables metadata_overlay in /etc/portage/modules, all of the cache files contained in /var/cache/edb/dep/${PORTDIR} must be manually removed in order to avoid unecessary cache regeneration. In addition, users of the metadata_overlay module must never modify eclasses in ${PORTDIR} because portage will not be able to detect that cache regeneration is necessary. If the user would like to modify eclasses, it is safe to use metadata_overlay together with PORTDIR_OVERLAY in make.conf.

Last edited by steveL on Wed Oct 30, 2013 9:17 pm; edited 1 time in total

This is really simple, but there's a small gotcha, which is you need a repo_name file in profiles subdir, or portage will complain that the PORTDIR directory structure is invalid. Secondly, there's no more old-style make.conf PORTDIR_OVERLAY="/usr/local/portage", and we need to give it a layout.conf. The Wiki has a page on this, so check that too.

We normally use: /usr/local/portage since that keeps it out of the portage tree (eg if we want to use a different fs for the tree, or wipe it and reformat, when distfiles is another mount), and is in the correct place for just this machine:

Using the overlay:
Remember the directory structure should mirror the one under /usr/portage. So, for example, an apache ebuild you've patched would go in directory /usr/local/portage/www-servers/apache.

Before you can use it, you have to cd to the overlay ebuild directory and run:

Code:

repoman manifest

This will download any sources you need, but not any patches etc: they live in the files/ subdir under the ebuild directory. It's easiest just to try emerging the ebuild (-av will tell you it's coming from the right overlay; it'll show ::aname after the version) and cp any files needed from the portage tree.

You can also add licenses which are not in the main tree under licenses subdir, and patch eclasses (if you have to-- better for writing your own) in ofc, the eclass directory.

The /etc/portage/repos.conf/ directory is made by portage (on upgrade, here) with the file /etc/portage/repos.conf/gentoo.conf:

Overlays are selected according to the priority; the gentoo one defaults to -1000. The example in the manpages shows how to do what I call "underlays", that is developer-overlays which defer to gentoo (at priority 0), instead of overriding it. In the older setup, PORTDIR was the default, and only consulted if the ebuild was not in the other overlays. We want our local one to be looked at first, though that's only where there's a choice of ebuilds with the same version. A higher-version in a lower-priority overlay, is still chosen as "best-visible."

The "best-visible" is the latest one according to your profile and any masking/ keyword settings (plus ebuild dependencies.)
The newest best-visible is always picked, irrespective of which overlay it's in; the ordering only comes into play for equal versions of the same best-visible.
It can be confusing if you don't know about that aspect; the idea is that if the tree moves forward with a newer version, you want that version for the default user-case. If not, use a cat-foo/pkgbar::overlay mask.

Overlays were selected in inverse order to the listing in PORTDIR_OVERLAY (ie latest takes precedence). The newer setup is more flexible, at the price of a bit more complexity (and I wouldn't want to debug the interaction of more than a very few overlays;)
To see the current situation for your setup use:

Code:

portageq repos_config /

There's no manpage for portageq though portageq(1) is mentioned in man emerge.
Run portageq -h instead.

So by setting our priority to 10000, we have plenty of space below, for any overlays we might install, as well as underlays we might work on, and can still override by dropping a patched ebuild and/or files, into /usr/local/portage just as we always have.

(Note that if you want to use crossdev, its overlay needs a higher-priority still.)

Last edited by steveL on Thu Nov 26, 2015 11:34 am; edited 13 times in total

# Ignore a version that is identical to the previously merged version,
# even though it is different from the current user modified version
# Note that emerge already has a similar feature enabled by default,
# which can be disabled by the emerge --noconfmem option.
# (yes or no)
ignore-previously-merged=no

Then run dispatch-conf.
The first few files, everything will be like it is now, but with the config from above, dispatch-conf stores every file and does replace it automatically if you have not changed it.
==

edit: add comment about --noconfmem, and set ignore-previously-merged to no instead of yes, so that we see changes when we use the latter option.

Last edited by steveL on Fri Sep 26, 2014 3:17 am; edited 1 time in total

Great post on making an updated install stage. I've been building chroots for the last couple of months while working on update and am thinking to write a script to replicate my current setup from a stage3. I've built loads of chroots, especially since I started using a binhost, and have started a script which takes care of the base build based on user menu selection.
Anyhow, I'll add stuff to this post, so far we have:

Hostname, and configs
We can copy from existing system, or the config file dir. And the user should be able to edit any config file from a selection and revert changes in case of problems. Eg making sure the CFLAGS are correct (for a single-user reinstall) is important, as are any base USE settings.

Update system then emerge -e world
First run of system and world we can do -X, imo. It's better to build it up slowly, get the machine booting and see.

umount /dev /proc from the chroot and then tar the installation (this is within chroot):

Code:

cd / && tar -cvjp ./ -f $(date +%Y%m%d)-baseline.tar.bz2

Gives a base stage. It would be fun to play with that in a vm as well.

Suicidal wrote:

For future installs I just update the existing chroot and then tar it up like I did before.

edit: cd / only applies in chroot.

Last edited by steveL on Wed Oct 30, 2013 9:21 pm; edited 1 time in total