On Tue, 2009-01-06 at 10:37 -0500, Jeremy Katz wrote: > 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 > You can do it with mergerepo - where you essentially have N repos and you merge their metadata but the pkg locations point back to whereever you got the repos from originally. The only negative of how this is done is that it means you can't use mirrors for the pkgs b/c now the pkgs have a baseurl specified w/i them. look at mergerepo in createrepo in 0.9.6+ for info on it. -sv _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
