When experimenting with LiveCDs and stages, or building custom LiveCDs, it is usefull to be able to have catalyst use portage tree overlay in adition to normal snapshot. Attached patch does this by rsyncing overlay directory on top of portage tree being tared, during portage snapshot building process. Reproducible: Always Steps to Reproduce:
Created attachment 31432 [details, diff] portdir_overlay patch
*** Bug 51580 has been marked as a duplicate of this bug. ***
fixed in CVS - its a new snapshot specfile arg, portdir_overlay
This idea of using overlay in catalyst is good, but the solution is less than perfect. The problem is that all the overlayed information will be lost in the first 'emerge sync', which is probably not the intension. If you have created you own packages or overlayed official ones, this information gets lost (unless you sync the overlay somehow). The problem gets even worse if you use your own profile as catalyst makes the symlink /etc/make.profile. When the overlayed information is lost (with will happen during a normal installation when you sync), the symlink becomes invalid and you got yourself a broken system. Of course you can always just create a new symlink, but the users of your stage have to know that. This unintended behavior also makes stages unsuitable for automated installation (as you have to fix the overlay and the symlink manually). I'm not sure what the best way to solve this, but I will look into it in a week or so.
OK. I've thought some more about this and I think I have a solution. Catalyst must make 2 snapshots : one snapshot of the official ebuild tree and one of the overlay. And then catalyst must unpack both separatly. Anyway, this is just my 2c. I will begin making the patch that implements this, but comments are most welcome..... especially "don't do that because..." comments if there are any ;-)
What is the point of that? Especially considering it works already. As for why not do it - rather simple - the way it is done now (overlay overwrites portage in tarball), we save both space and time. If there is duplicate ebuild in overlay, let's say with bug fix, it will overwrite same ebuild in tarball. On my machine, where unpacking tarball is probably slowest, and definitely not parallelizable process, it may be important, and noticable.
what's the status of the second approach ? For my uses this works out very well because I have my own local portage tree with my own software. If there was a portage snapshot plus an overlay snapshot(it does not overlap with portage software in anyway) in the catalyst build I could keep my personal ones seperate from gentoo mainline.
First of all : sorry for the late answer. I've been very busy, so this problem have been given a lower priority. "The second approach" as you call it will come, when I get some time to make the patch. As Ilya Volynets has pointed out, the current implementation works for most people and the erroneous behavior is apparently only obvious to people, who (like my self) combines catalyst with custom profiles and heavy overlaying. And there are work-arounds for the current implementation. However it still handles overlays wrong, so I will make a patch eventually....however it will take a while, as I have to learn some python first ;-) Whether the patch will be accepted or rejected will up to the maintainers of catalyst.
If you need your own snapshot of your own overlay - just put it into livecd-overlay and have it unpacked by some script during install. Perhaps if you get that working - sample scripts to do that should be added to catalyst exaples.
