When I update a Gentoo system, does Portage fetch new sources, extract them and recompile everything from scratch, or does it extract it to existing sources and compile only changed files?
Does Portage rebuild full packages when updating
gentoopackage-managementportage
Related Solutions
As far as I know it is not possible. Please remember that toolchain does not exist in vaccum and is interlinked.
What might work is to build cross-compiler of new infrastructure but I really doubt it - the "atomicity" on update of glibc will break everything.
I would advice backup & reinstall of system.
Well, first off all, what do you have to loose? If it doesn't work out, you can still do a fresh install.
Backup
It goes without saying that you need to backup important items. Maybe even do an archive of /etc, in case you want to look back.
Personally, whenever I try something radical, I rsync my root file system to a separate disk beforehand. Whenever something goes terribly wrong, I just rsync it back ;). Mount the root partition on a separate mount point, to prevent recursion to all mounted partitions. And run something like:
rsync -av --delete /mnt/root/ /mnt/backup
To restore:
rsync -av --delete /mnt/backup/ /mnt/root
Just make sure that the backup file system is a linux type (not FAT or NTFS), to transfer permissions, symlinks and file ownership correctly up and down.
Although never done personally, you could try the below options as a guideline. Some comments above suggest different compiler profiles, but most of that are just useflags to gcc and CFLAGS in make.conf, I don't see the real issue there.
Option #1
What you could try, but no personal experience, is do it the repo.conf way. Create a separate directory, like /usr/gentoo and put the vanilla Gentoo portage tree there.
File /etc/portage/repos.conf/gentoo.conf:
[DEFAULT]
main-repo = gentoo
[gentoo]
location = /usr/gentoo
sync-type = rsync
sync-uri = rsync://rsync.gentoo.org/gentoo-portage
auto-sync = yes
priority 10
And something similar should exist for Funtoo, and with a lower priority. After you run emerge --sync, both trees will exist next to each other. If same version packages exist, the repo with higher priority wins (in theory). You can force package selection, by suffixing the desired repo like this:
emerge sys-devel/gcc::gentoo
Using this setup you can move to Gentoo step-by-step. The profiles from both repositories will be available for selection, so you can try out some emerge --pretend commands when selecting the Gentoo profiles, play around with useflags etc. Emerge gcc, portage from the Gentoo tree etc. If you just make sure that GCC is re-emerged with the same useflags (edit make.conf to your liking) and you keep the same CFLAGS, you probably don't even need to empty the system tree.
Maybe you want to read the GCC upgrade guide, and /usr/share/portage/config/make.conf.example.
Finally, you could drop the repo.conf entry for funtoo and do a emerge -uND --newrepo @world.
Option #2
In the past, when I was doing some big profile change, I used this method.
- Make sure your system is completely up-to-date (
emerge -uND @world), handle the @preserved-rebuild set and depclean. - Move the entries from
/var/lib/portage/worldinto a user defined set. This can be one set, or if you want to be organized, categories of sets. For instance, I created 3 sets, usable in separate stages of the process.
/etc/portage/sets/boot
sys-boot/grub
sys-kernel/gentoo-sources
[network tools etc]
/etc/portage/sets/admin
app-editors/vim
app-portage/gentoolkit
[...]
/etc/portage/sets/desktop
# All the rest
Make sure that /var/lib/portage/world and word_sets are both empty files after this migration.
- Run
emerge --depcleanto get rid of all packages that where pulled in by@world - For now, clean out
/etc/portage/package.use. (Move the file(s) somewhere if you intend using it later again. - Comment out the
USE=line inmake.conf - Drop to a simple as possible profile. In gentoo it would be something like:
default/linux/amd64/17.0 emerge -uND @world && emerge --depcleanYou will be in the smallest configuration possible for Funtoo, smallest risk on conflicts.- Swap the portage tree to use Gentoo's one. (Probably in
repos.conf) - This should give you the simplest Gentoo profile system emerge -1 sys-apps/portage emerge -1 sys-devel/gcc emerge -e @system
emerge @bootAnd do what you need to do to conigure the kernel, grub etc. (follow the handbook) This should give you a completely reboot-able Gentoo system. Reboot if you want to test at this point.- Set your desired profile, re-enable useflags in
make.confand maybe package specific flags inpackage.use emerge -uND @world @admin @desktop && emerge --depclean: if this went ok, you have successfully transferred Funtoo to Gentoo!
Incompatibilities
To answer the remaining questions;
During the re-intallation of packages, portage will check if file in /etc/ are the originals or modified. If they are un-modified since installation, portage will just replace them. Same goes for files in /etc/init.d. These files, in the end, all belong to a package. A package rebuild should give the right version in the end.
Modified config files are protected by config-protect. These will need to be updated using tools like etc-update.
Note
I am aware this was an old question and probably doesn't help the OP anymore. However, the subject interests me. It would be nice if someone who came across this answer will give it an actual try :).
Best Answer
While
make(1)and many buildsystems, such as autotools, do support incremental compilation, Gentoo with stock Portage does not take advantage of it. After a package is compiled and installed, the working directory is discarded.The actual difficulty with using incremental compilation would be getting packages to build reliably in this fashion. It is much easier to be assured that a build will be both successful, correct, and reproducible if you always do a clean build. Many buildsystems would break subtly if Gentoo tried to support rebuilding incrementally. And, in many cases, one would have to re-run
./configure(or its equivalent) which would likely create a newconfig.hor update environment variables such asCFLAGSandCPPFLAGSin the generatedMakefiles (or equivalents if other buildsystems are used). Touchingconfig.hwould require most sources to be rebuilt. And ifPACKAGE_VERSIONchanges, which might be passed byMakefileviaCPPFLAGSif the package doesn’t useconfig.h, all sources should be rebuilt to see the new values—unless you can somehow figure that certain source files wouldn’t need to be recompiled because they don’t reference a particular C preprocessor macro.So, in the end, even if Gentoo devs went to all the work to try to support incremental compilation between package version updates, many packages would either need to be fully recompiled or
make(1)would end up fully recompiling them anyway (e.g. ifconfig.h’s timestamp changes). So this would be a high cost effort for a very marginal gain—and even likely introduce a lot of subtle bugs, in my best understanding. Thus, I do not expect such a feature to ever be introduced.My answer mostly refers to autotools/simple
Makefile-type packages, but not everything builds this way, so the exact reasons would likely differ depending on the exact package in question.