Bug 617032 - yumdownloader resolving dependencies issue
yumdownloader resolving dependencies issue
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: yum-utils (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-21 21:29 EDT by David Brown
Modified: 2014-01-21 18:16 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-22 10:54:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Brown 2010-07-21 21:29:53 EDT
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.
Comment 1 James Antill 2010-07-22 10:54:32 EDT
> 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.

Note You need to log in before you can comment on or make changes to this bug.