Description of problem: Somehow the DVD.iso that is composed by pungi contains pieces of anaconda that are not derived from the anaconda*.rpm that is in the repo. Version-Release number of selected component (if applicable): pungi-2.0.4-1.fc10.noarch How reproducible: always Steps to Reproduce: 1. Run a compose with anaconda-11.4.1.34-1.i386 in the repo, but anaconda-11.4.1.33-1.i386.rpm installed (n.b. '33' vs '34'). The command I used was: pungi -c /usr/share/pungi/rawhide-fedora.ks --force --destdir=/data/Fedora10 --name Fedora --ver 10 --nosource 2. 3. Actual results: After burning and booting the DVD.iso, then the installer announces itself as 11.4.1.33 (the version that is installed on the machine that ran the pungi compose.) Expected results: The installer announces itself as 11.4.1.34 (the version that is in the repo.) Additional info: /usr/lib/anaconda-runtime/buildinstall near line 168 always downloads anaconda from the repo, and then unpacks some new pieces for use: ----- pushd $BUILDINSTDIR BUILDARCH=`repoquery -c $yumconf --qf "%{ARCH}\n" anaconda` yumdownloader -c $yumconf anaconda || exit 1 rpm2cpio anaconda*rpm | cpio --quiet -iumd './usr*' rm -f anaconda*rpm popd for f in $UPD_INSTROOT $MK_IMAGES $MK_STAMP $MK_TREEINFO $BUILDINSTALL; do if [ -n "$UPDATES" -a -f $UPDATES/usr/lib/anaconda-runtime/$f ]; then cp -a $UPDATES/usr/lib/anaconda-runtime/$f* $BUILDINSTDIR/ elif [ ! -f $f ]; then cp -a $BUILDINSTDIR/usr/lib/anaconda-runtime/$f* $BUILDINSTDIR/ else cp -a $f* $BUILDINSTDIR/ fi done ----- It is unclear whether this covers *all* the pieces of anaconda that go into the composed DVD.iso. The pungi console announces: Pungi:INFO: Running /usr/lib/anaconda-runtime/buildinstall --product Fedora ... which obviously uses the installed buildinstall for some things. Perhaps using it for "control" of the compose process itself is OK, but using it for "data" that appears in DVD.iso is questionable. If the installed buildinstall does leak some of its pieces into DVD.iso, then pungi should warn if buildinstall does not correspond to the anaconda in the repo. The fact that buildinstall always downloads anaconda means that it is dangerous to use the --mirrorlist= construct in the pungi *.ks file. There is no record of which mirror supplied which actual version of anaconda, and it is unclear what kind of consistency checking gets performed [in particular, the version seen by pungi vs the version seen by buildinstall.] Mirror skew exists today and is unlikely to be eradicated soon. Because downloading is non-instantaneous, then even the same mirror can have skew between the beginning and the end of a pungi compose.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is on purpose. pungi tries to use as much of the locally installed anaconda as possible. In fact, in future rewrites of buildinstall scripts, they won't download a new anaconda and instead pull the bits from the installed anaconda.