--- Jeremy Katz <katzj(a)redhat.com&gt; wrote: ... Cool. So here are my comments, based on how I would like to use it eventually with my qfakeroot "no root privs, but slow as molasses" framework. Currently my tools, being influenced heavily by qemu, deal with qemu disk images as the fundamental object. First, I have a frontend which generates the qemu disk image from a kickstart file. This frontend is meant to be a module, with alternate ones which support ubuntu etc in the future. I would like to use this new livecd-creator API to create another optional frontend, which does things the 'fedora standard' way. I think what you described will work fine for my purposes, i.e. generating an ext3fs. The thing of course is what you noted, and how it currently does nothing to set up booting. I would like to see the same anaconda code that sets up booting, be available somehow (easily/intentionally) such that I could use it to finish generating a complete system image. It may be interesting to ponder this, and the method I currently use - running traditional anaconda purely non-interactively under qemu, and then think about code sharing/duplication issues. The next thing I'd like to do is- just as taking the image generation part of livecd-creator and making it an optional frontend in my root-less system, is take the livecd packaging part, and make it an optional backend in my system. I suppose from what you outlined, this seems pretty doable, as I would probably just make the non package image methods, just mount the stuff from the prior created qemu image. Perhaps before or after I try to do all of the above, I may also just try to get livecd-creator to detect if it's not being run as root, and if my qfakeroot tool is installed, and if so, run itself under there. Another interesting smaller qfakeroot+livecd-creator integration would be to detect running on an selinux disabled system, and if the target livecd is selinux enabled, use qfakeroot just for the restorecon operation (which is currently not possible). Anyway, I've got some paradise to go explore... afk for a few days ;) peace... -jdog ____________________________________________________________________________________ Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/

On Sat, 2007-11-17 at 18:07 -0800, Jane Dogalt wrote: Because that pulls along a lot of things which deal with the specific flow of system installation. Making it so that the anaconda frontend to doing all of that is more usable for other methods is something I've spent way too long and thought way too hard about before going this route... but doing that is going to be a far longer path. One thing to read between the lines of what some of the exposed API, etc underneath livecd-creator is that the fact that we're using a pykickstart object to describe the configuration is very important. Because the longer-term idea is to move the anaconda instdata stuff to instead be based on the pykickstart objects. And then we'll move all of the interesting code there to be shared. Jeremy

I've taken a good look at the proposed API and for now I'll just state some items where I have some questions, doubts or concerns on how to perform what it is we need to perform. * In the 'image.InstallPackages()', would it be possible to not use the yum object provided by livecd-creator itself? Given that tools built upon livecd-creator may already have a complete yum object it could be useful to hand over the yum object to this function * In conjunction with the previous question would it be possible to not have livecd-creator set up it's own yum object -merely an efficiency question and completely secondary-? * For any type of extra configuration or external configuration (e.g. non-kickstart), would it be possible to have variables such as 'build_dir', 'yum_cache' and '_instroot' defined in (for example) __init__() so that once we create a class instance we can override them with another value? More specifically; if we call ImageCreator.setup() directly now, there's nothing we can do anymore to point our existing yum installroot to the 'install_root/' directory under which the loopback filesystem is mounted. More granular functions all doing little, very little bits and pieces might help too. Regarding this I see ImageCreatorBase._get_instroot() and _instroot = property(_get_instroot) -I'm not sure how I could override that -if possible. * Can we please drop the '-' in the 'livecd-creator' file so that we can import it? It'll be a lot easier for us to provide actual feedback in the form of patches, on what we need changed in the API. Kind regards, Jeroen van Meeuwen -kanarip Jeremy Katz wrote:

On Thu, 2007-11-22 at 03:19 +0100, Jeroen van Meeuwen wrote: The reason why this is done is because this is _explicitly_ an abstraction. The fact that it uses yum today doesn't mean that it'll use yum tomorrow. Even if we continue to use yum, it makes it so that it's possible to change out the yum API (which is likely to be occurring sooner or later) while not having to make changes to the interfaces of livecd-tools. And yes, I feel very strongly that this is the only way to be able to have consistency in bits built. Otherwise, every user that makes use of the functionality has to implement their own equivalent depsolving, etc. The idea, though, isn't that you override every little bit and piece of everything. For one thing, it leads to an API that is a bit out of control and wild. For another, it makes things incredibly difficult to follow and implement. Overriding the builddir and the instroot just isn't that interesting -- they're temporary bits that are blown away on errors, after things are done, etc. The cachedir there's already a way to override at which point, you know what it is (see the cachedir arg to mountImage()) Jeremy

On Mon, 2007-11-26 at 16:40 +0100, Jeroen van Meeuwen wrote: I know we've been around and around on this, but I really still don't see your hang-up over having your own hand-constructed yum object rather than making use of what's created, used, etc by the API. And I think that's the crux of your other comments is that you want things so that you can have your own yum object. That's just done that way because it's how Colin's patch originally did it. I'm not at all tied to keeping the /yum-cache bit there. Jeremy

Hey, I've taken Jeremy's repo and done further re-factoring, mostly with the aim of cleaning up the sub-classing API and making it a lot more clear what is and isn't part of the API. I think the whole codebase is much cleaner now, though, and I've even added docs ! :-) Please take a look at: http://markmc.fedorapeople.org/git/livecd-tools.git Comments are very welcome - e.g. what's exposed in the sub-classing API might be a little conservative right now. Cheers, Mark.