Description of problem: yumdownloader not getting all the resolved dependancies. Version-Release number of selected component (if applicable): yum-utils-1.1.27-2.fc13.noarch How reproducible: simple'ish the bug was discovered when attempting to use cobbler to download specific packages from a repository. Cobbler's logic when given a set of packages from a repository to download chooses yumdownloader instead of reposync. Steps to Reproduce: 1. create a yum.conf file that looks like this: [centos-5.5-x86_64-core] name=centos-5.5-x86_64-core baseurl=http://mirror.pnl.gov/centos/5/os/x86_64 enabled=1 priority=99 gpgcheck=0 2. /usr/bin/yumdownloader --resolve --disablerepo=* --enablerepo=centos-5.5-x86_64-core -c yum.conf --destdir=. SysVinit.x86_64 authconfig.x86_64 basesystem.noarch bash.x86_64 centos-release.x86_64 centos-release-notes.x86_64 coreutils.x86_64 cpio.x86_64 e2fsprogs.x86_64 ed.x86_64 file.x86_64 filesystem.x86_64 glibc.x86_64 hdparm.x86_64 initscripts.x86_64 iproute.x86_64 iputils.x86_64 kbd.x86_64 libgcc.x86_64 libtermcap.x86_64 mkinitrd.x86_64 passwd.x86_64 policycoreutils.x86_64 prelink.x86_64 procps.x86_64 readline.x86_64 redhat-logos.noarch rootfiles.noarch rpm.x86_64 selinux-policy-targeted.noarch setools.x86_64 setserial.x86_64 setup.noarch shadow-utils.x86_64 sysklogd.x86_64 termcap.noarch util-linux.x86_64 vim-minimal.x86_64 kernel grep.x86_64 net-tools.x86_64 tzdata.noarch grub.x86_64 Actual results: Well things that should have been brought in are missing. gawk which initscripts requires doesn't get brought in. libacl doesn't get brought in which coreutils requires (iirc). Things like that. Expected results: I expected all packages from a `yum --installroot=/foobar groupinstall @Core' where /foobar is a clean empty directory to show up in the download directory when yumdownloader was called. Additional info: So this does look crazy but I think it boils down to a question. What's the logic for stopping the resolution of a `yumdownloader --resolve'? if its the current state of the system, how can I tell it to ignore that? From a cobbler perspective this was probably a bad choice to use since it depends on the current state of the cobbler server as to what packages get tossed into a repository you create using this method. Logic for doing a "deep resolve" of packages from a repository using yumdownloader would be to lookup things like /bin/awk or libacl.so.1 then if its not provided in the packages you are configured with then don't download them.
> I expected all packages from a `yum --installroot=/foobar groupinstall @Core' > where /foobar is a clean empty directory to show up in the download directory > when yumdownloader was called. ... > So this does look crazy but I think it boils down to a question. What's the > logic for stopping the resolution of a `yumdownloader --resolve'? if its the > current state of the system, how can I tell it to ignore that? It is the current state of the system. The F-13 yum-utils/yumdownloader does use --installroot so you can do: yumdownloader --installroot=/tmp/blah-$RANDOM --releasever=13 --resolve zziplib --utls ...however the --releasever there isn't acted on atm. (patch just went upstream), but you don't seem to need that. You can also use "yum-plugin-downloadonly" with --installroot. If none of those work feel free to reopen.
To be clear: I do NOT want to reopen this bug. I just wanted to point out that cobbler has an option in settings (typically /etc/cobbler/settings) called "yumdownloader_flags". You can add "--installroot=/foobar/" there, so that reposync for that partial repo will better be able to resolve dependencies.