Greetings,
In bug#567706, Andre Robatino asked whether the test case QA:Testcase_Mediakit_Repoclosure [1] should have found the reported issue. I suspect it should have.
While retesting, it appears that the following repoclosure command correctly identifies the missing dependency:
$ repoclosure --repofrompath=media,/media -a x86_64 -r media -n Added media repo from /media Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 1 media Num Packages in Repos: 3256 package: 1:xorg-x11-drv-nouveau-0.0.16-0.20100205gite75dd23.fc13.x86_64 from media unresolved deps: kernel-drm-nouveau = 0:15
However, when run without the '-n' option, as documented in the test case [1], it does not detect bug#567706.
repoclosure --repofrompath=media,/media -a x86_64 -r media Added media repo from /media Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 1 media Num Packages in Repos: 3261
Afaik, the packages on the mediakit should not contain multiple versions of a package, so I'm unclear why adding the -n|--newest flag captures the missing deps.
Thanks, James
[1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_Repoclosure
On Tue, 23 Feb 2010 15:33:12 -0500, James wrote:
Greetings,
In bug#567706, Andre Robatino asked whether the test case QA:Testcase_Mediakit_Repoclosure [1] should have found the reported issue. I suspect it should have.
While retesting, it appears that the following repoclosure command correctly identifies the missing dependency:
$ repoclosure --repofrompath=media,/media -a x86_64 -r media -n Added media repo from /media Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 1 media Num Packages in Repos: 3256 package: 1:xorg-x11-drv-nouveau-0.0.16-0.20100205gite75dd23.fc13.x86_64 from media unresolved deps: kernel-drm-nouveau = 0:15
However, when run without the '-n' option, as documented in the test case [1], it does not detect bug#567706.
repoclosure --repofrompath=media,/media -a x86_64 -r media Added media repo from /media Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 1 media Num Packages in Repos: 3261
Afaik, the packages on the mediakit should not contain multiple versions of a package, so I'm unclear why adding the -n|--newest flag captures the missing deps.
Thanks, James
[1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_Repoclosure
Did you notice the difference in the "Num Packages in Repos" line? With -n there are five pkgs less than without -n.
On Tue, 2010-02-23 at 21:45 +0100, Michael Schwendt wrote:
On Tue, 23 Feb 2010 15:33:12 -0500, James wrote:
Greetings,
In bug#567706, Andre Robatino asked whether the test case QA:Testcase_Mediakit_Repoclosure [1] should have found the reported issue. I suspect it should have.
While retesting, it appears that the following repoclosure command correctly identifies the missing dependency:
$ repoclosure --repofrompath=media,/media -a x86_64 -r media -n Added media repo from /media Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 1 media Num Packages in Repos: 3256 package: 1:xorg-x11-drv-nouveau-0.0.16-0.20100205gite75dd23.fc13.x86_64 from media unresolved deps: kernel-drm-nouveau = 0:15
However, when run without the '-n' option, as documented in the test case [1], it does not detect bug#567706.
repoclosure --repofrompath=media,/media -a x86_64 -r media Added media repo from /media Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 1 media Num Packages in Repos: 3261
Afaik, the packages on the mediakit should not contain multiple versions of a package, so I'm unclear why adding the -n|--newest flag captures the missing deps.
Thanks, James
[1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_Repoclosure
Did you notice the difference in the "Num Packages in Repos" line? With -n there are five pkgs less than without -n.
Yeah, exactly. Very odd. The only way adding --newest would fail and not using --newest would work is if there were multiple kernel packages on the RC2 DVD media. Sure enough ...
-rw-r--r--. 2 root 101737 22268072 2010-02-20 16:24 /media/Packages/kernel-2.6.33-0.46.rc8.git1.fc13.x86_64.rpm -rw-r--r--. 2 100351 101737 22185504 2010-02-22 23:01 /media/Packages/kernel-2.6.33-0.51.rc8.git6.fc13.x86_64.rpm
Closer inspection shows ..
$ rpm -qp --provides kernel-2.6.33-0.46.rc8.git1.fc13.x86_64.rpm | grep kernel-drm-nouveau
kernel-drm-nouveau = 15
$ rpm -qp --provides kernel-2.6.33-0.51.rc8.git6.fc13.x86_64.rpm | grep kernel-drm-nouveau kernel-drm-nouveau = 16
Summary: by adding --newest, it chooses the .51 (newer) kernel above which does not satisfy the xorg-x11-drv-nouveau kernel-drm-nouveau = 0:15 dependency.
I'm guessing kernel-2.6.33-0.46 was pulled into the DVD compose to satisfy dependencies of xorg-x11-drv-nouveau, otherwise it doesn't make sense to have two of the same kernel packages on the media (kernel and kernel-PAE are different).
Should the test case [1] always use --newest since that seems to more closely mirror yum behavior during installation?
Thanks, James
[1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_Repoclosure
----- "James Laska" jlaska@redhat.com wrote:
Yeah, exactly. Very odd. The only way adding --newest would fail and not using --newest would work is if there were multiple kernel packages on the RC2 DVD media.
If I'm reading the --help page correct, by default repoclosure should check *all* packages, and with --newest it should check *only newest* packages. Therefore if a broken dependency is detected with --newest and is not detected without it, I assume it should be reported as a bug in repoclosure.
Should the test case [1] always use --newest since that seems to more closely mirror yum behavior during installation?
I believe we should check all packages available, that means no --newest. Assuming it works correctly.
The other question is - should we write/find another tool to detect duplicated packages on the install media and report an error if multiple versions of the same package are found there? Should that condition be always valid, or are there some exceptions?
Thanks, James
[1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_Repoclosure
----- "Kamil Paral" kparal@redhat.com wrote:
----- "James Laska" jlaska@redhat.com wrote:
Yeah, exactly. Very odd. The only way adding --newest would fail and not using --newest would work is if there were multiple kernel packages on the RC2 DVD media.
If I'm reading the --help page correct, by default repoclosure should check *all* packages, and with --newest it should check *only newest* packages. Therefore if a broken dependency is detected with --newest and is not detected without it, I assume it should be reported as a bug in repoclosure.
Yay, forget about my previous post, I got it wrong. I had to try it myself to understand it. Now I get it - not only repoclosure checks just the newest packages for broken dependencies, also those *dependant packages* (the targets) must be amongst the newest ones. I wonder if it is intentional or not.
Should the test case [1] always use --newest since that seems to more closely mirror yum behavior during installation?
Well, yum is able to work around this problem, isn't it? It should just select an older kernel for installation. I tried to simulate it on my F12 machine by adding a repo, but I failed to be completely sure.
On Wed, 24 Feb 2010 03:54:47 -0500 (EST), Kamil wrote:
Yay, forget about my previous post, I got it wrong. I had to try it myself to understand it. Now I get it - not only repoclosure checks just the newest packages for broken dependencies, also those *dependant packages* (the targets) must be amongst the newest ones. I wonder if it is intentional or not.
It is intentional, because an ordinary Yum update/install tries to pick the newest packages, too. A broken dep with only the newest packages is still a broken dep. Users may be keeping and running older kernels, but they would not be able to install the newest one, if that one suffered from broken deps.
Repoclosure does not and cannot simulate Yum's "installonly_limit" setting for kernel packages. Extras' repoclosure allows old kernel dependencies, but that is old cruft related to various kernel module add-on packages and late/slow rebuilds. As it also ignores kmod related broken deps in its report script since that feature was added, maybe it's time to revisit the kernel dep filter and drop it.
Should the test case [1] always use --newest since that seems to more closely mirror yum behavior during installation?
Well, yum is able to work around this problem, isn't it? It should just select an older kernel for installation. I tried to simulate it on my F12 machine by adding a repo, but I failed to be completely sure.
repoclosure -n ought to be the default. At least for Fedora. Allowing for older packages to resolve dependencies is sort of trying to simulate Yum's --skip-broken, which is against the purpose of a depchecker.
On Wed, 2010-02-24 at 12:02 +0100, Michael Schwendt wrote:
On Wed, 24 Feb 2010 03:54:47 -0500 (EST), Kamil wrote:
Yay, forget about my previous post, I got it wrong. I had to try it myself to understand it. Now I get it - not only repoclosure checks just the newest packages for broken dependencies, also those *dependant packages* (the targets) must be amongst the newest ones. I wonder if it is intentional or not.
It is intentional, because an ordinary Yum update/install tries to pick the newest packages, too. A broken dep with only the newest packages is still a broken dep. Users may be keeping and running older kernels, but they would not be able to install the newest one, if that one suffered from broken deps.
Repoclosure does not and cannot simulate Yum's "installonly_limit" setting for kernel packages. Extras' repoclosure allows old kernel dependencies, but that is old cruft related to various kernel module add-on packages and late/slow rebuilds. As it also ignores kmod related broken deps in its report script since that feature was added, maybe it's time to revisit the kernel dep filter and drop it.
Should the test case [1] always use --newest since that seems to more closely mirror yum behavior during installation?
Well, yum is able to work around this problem, isn't it? It should just select an older kernel for installation. I tried to simulate it on my F12 machine by adding a repo, but I failed to be completely sure.
repoclosure -n ought to be the default. At least for Fedora. Allowing for older packages to resolve dependencies is sort of trying to simulate Yum's --skip-broken, which is against the purpose of a depchecker.
Thanks for the feedback all. I've updated the test case instructions to use the "--newest" option.
Thanks, James