On Mon, 2009-01-05 at 16:27 -0500, Bill Nottingham wrote: > I was working on composing a custom distro based on Fedora 10, > and I kept running into various minor issues that made the process > not work as well as I'd like. I'm cataloging these here, in case > I'm missing something obvious that I should be doing instead of > what I did. > > 1) Fedora and RHEL installclasses are directly in anaconda > > To override/remove them, you get to remove them in a custom > package's %post, and also with a %triggerin on anaconda This has always been the case -- if you want something more custom, the right path is likely a product.img being built for your tree and dropped into images/ > 2) BETANAG is a constant in anaconda itself > Again, you get to modify anaconda files in %post/%triggerin BETANAG was (historically) more about anaconda being beta than anything else > 3) anaconda and pungi don't support identical repo definitions > To override packages in the base repositories, I can set up > a local repository with packages that obsolete the base repo > packages, and set cost appropriately (or --exclude/--include.) > anaconda ignores all of this when building install images, > causing me to have to go to dirty hacks to not pull in > packages I don't want. You mean buildinstall here? > 4) repo editing, and the 'built-in' repos > Say you're composing a custom distro, with a custom comps file, etc. > How do you set up the post-install repo files for yum correctly? > > Your choices are: > > 1) use the 'upstream' Fedora repos. In which case you have to tell > it to ignore the group file, and anaconda's built-in repo support & > repo editing will point to/enable those repos by default > 2) mirror everything into your own custom repos based on what you're > building with pungi. This is waste of space, and also means that > you have to make a custom <foo>-release package that points to these > custom repos... before you even build them. (And if you're doing > the normal spin, fix, spin, fix cycle, you get to keep > resyncing/recreating that tree.) If you're really doing something custom, I'd expect you don't want 1 in any case. The third option is that the repodata can point to an alternate baseurl iirc; so then you could just have a set of repodata that then points to a separate repository of packages. But I don't remember the createrepo invocation needed to make that happen, I just remember having the discussion with Seth about the possibility of doing it in the context of making a few things nicer with koji Jeremy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
