The idea is to have the ability to define functions that will be called before/after build steps. This is similar to portage's bashrc phase hooks.
I think this would be very useful, but since nothing has happened since you proposed this I would like to suggest a similar but simpler improvement. Several times I found that I can work around some problem by editing stageN-chroot.sh. I have done so for example to work around bug 207553. More commonly the problem was a circular dependency or a similar problem that can easily be fixed on a live system. By editing the chroot script one can basically do the same within catalyst. So I propose an option that allows setting the chroot script of a stage. You probably would not use this feature for the official releases, since it is not very clean. But for people who want to build their own custom stages this would be very useful.
So much for the technical aspects. Here is why it is good for the user and releng too. Catalyst isn't primarily intended for users to create their own stages I know. But it seams that is very natural for them [1] to want to create their own stages [2]. If the last release has been made a long time ago or if he wishes to make the stage more like his live system (which he does!, like adding X11 or emacs), it's just unlikely that he won't hit a bug that prevents building stages that he cannot easily fix himself or will be fixed in a short period of time (e.g. bug 166937) after being reported here. [1] People get a new computer or fuck up and have to start over. One only learns something so often when installing gentoo (including X11...), after that it just gets annoying. [2] I haven't really heart from a lot of people who do so, but I guess they just give up after they run into problems that can be worked around by modifying stageN-chroot.sh If you don't want to follow my suggestion (which is perfectly okay), it would be nice if you could update the documentation to suggest that editing stageN-chroot.sh can be used to fix problems. It would be useful if the chroot scripts would be confproteced. Handling catalyst in itself isn't really hard, but working around the bugs that come to light when doing so is. At least until one realizes that the chroot functions can be modified. There is something in it for releng too. If more people use catalyst more often, bugs will be known longer before the next release, which gives you more time to find a clean solution. If you don't give users a change for a dirty but just good enough workaround, they might just give up and "forget" to make a bug report.
This was more of an internal bug reminding me to implement the feature at some point in the future. There are multiple problems with your approach. First and foremost, if you have to edit one of the -chroot.sh scripts to get around a blocker, then you're doing it wrong. You need to build all of your seed stages (starting at stage1) with the same snapshot. Second, your method makes a build non-reproducible, which is a big no-no (in our eyes). It's a lot simpler to distribute your envscript with a set of specs than it is to distribute a modified copy of a chroot script. Also, my method is more likely to work with different versions of catalyst, where your method is very much version specific. Bottom line, no :P
> First and foremost, if you have to edit one of the -chroot.sh scripts to get > around a blocker, then you're doing it wrong. Well if there is a bug in some of the ebuilds that I need then I either need to fix the bug or work around it. Of course fixing the bug is the correct way, but sometimes (for some people) this isn't practical. So I can either work around it or give up. > You need to build all of your > seed stages (starting at stage1) with the same snapshot. That's what I am doing. Some packages that get emerged during stage3 have a useflag "emacs" which I have enables in my custom profile. Additionally I have unmasked emacs-cvs-23 triggering bug 207553). There are no such packages during stage1 and stage2, that's the only reason why does stages are not affected. > Second, your method makes a build non-reproducible, which is a big no-no (in > our eyes). It's a lot simpler to distribute your envscript with a set of specs > than it is to distribute a modified copy of a chroot script. Thats exactly what I try to overcome, I think you might not have understood me correctly. I propose options stageN/chrootscript that can be set in the spec file just like e.g. stage4/fsscript. So it is reproducible. I don't see how it is complicated to distribute stage3-chroot.sh in addition to fsscript.sh. > Also, my method is > more likely to work with different versions of catalyst, where your method is > very much version specific. Nothing against your method, it's much more flexible. I just suggested a method that might be easier to implement, since you haven't had the time to implement yours. I think my method is just the poor-mans-version of yours. > Bottom line, no :P Very well then, grrr >:)= It works for me the way it is now, and gave me a reason to look at the patch-applying-code in subversion.eclass. But as I have said, I think this might keep people from using catalyst, which would benefit releng and the community. So don't be surprised if I put up some hint up somewhere about my dirty ways (with a reverence to this discussion of course) :P
