Jeremy Katz (katzj@xxxxxxxxxx) said: > > 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/ Which is significantly more effort to wire into pungi (and also travels down codepaths we don't normally exercise.) > > 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? Yes. > > 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 Right, but again this isn't easily done in our tools. In any case, if you're doing something really custom, I don't see a way around having to make your <foo>-release point to repos that you haven't built/published yet, which is sort of weird. (Or you point them somewhere interim so you can test.) We work around this for Fedora due to rawhide being public and 'close enough' to what we're composing, along with some mirrormanager tricks. Bill _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
