TW dup to local repo packages tried to remove 53 kde3 packages -- what to check?
Devs, All, I created a signed local repo with patched Nvidia packages for the G04 driver. My intent was simply to: # zypper -r mynvidiarepo dup To move all Nvidia packages to the versions in my repo. When I did, zypper proposed updating the 7 driver packages, but then also proposed removing most of the kde3 desktop (53 packages). I'm at a loss to why zypper would propose the removal of unrelated packages when simply trying to update Nvidia drivers. My first thought was there must have been some problem with the .spec and dependencies -- but I can't imaging what that would be. Where would I start to look for why zypper proposed the removal of the kde3 packages on change of versions for the Nvidia drivers? To work around this problem, I simply rsynced the repo to my laptop and then did a: # zypper in *.rpm Which worked fine and didn't suggest uninstalling anything. So what's the difference in dup or in for the package removals? (I would have copied the zypper dup output -- but the dkms driver build scrolled everything out of the xterm buffer :( Thoughts? -- David C. Rankin, J.D.,P.E.
On Tue, Aug 13, 2024 at 11:43 PM David C. Rankin <drankinatty@gmail.com> wrote:
Devs, All,
I created a signed local repo with patched Nvidia packages for the G04 driver. My intent was simply to:
# zypper -r mynvidiarepo dup
To move all Nvidia packages to the versions in my repo. When I did, zypper proposed updating the 7 driver packages, but then also proposed removing most of the kde3 desktop (53 packages).
I have seen similar reports about "zypper dup -r" behavior (actually, IIRC zypper suggested removing almost everything).
I'm at a loss to why zypper would propose the removal of unrelated packages when simply trying to update Nvidia drivers. My first thought was there must have been some problem with the .spec and dependencies -- but I can't imaging what that would be. Where would I start to look for why zypper proposed the removal of the kde3 packages on change of versions for the Nvidia drivers?
To work around this problem, I simply rsynced the repo to my laptop and then did a:
# zypper in *.rpm
Which worked fine and didn't suggest uninstalling anything. So what's the difference in dup or in for the package removals?
The primary goal of "zypper dup" is to bring your system as close as possible to the current content of the currently used repositories. When doing it zypper will aggressively remove any orphan package if it is required to solve dependency problems. Now, if you do "dup" with only one repository, *everything* on your system is orphaned. To find out what caused zypper to remove these packages the complete state would be needed (that is usually generated by "zypper --debug-solver", but I guess it is too late). Personally I consider using "zypper dup -r single-repository" as a "poor man's vendor switching" to be a very bad idea. "zypper dup" was simply not designed for it.
(I would have copied the zypper dup output -- but the dkms driver build scrolled everything out of the xterm buffer :(
Thoughts?
-- David C. Rankin, J.D.,P.E.
On 8/14/24 3:02 AM, Andrei Borzenkov wrote:
Personally I consider using "zypper dup -r single-repository" as a "poor man's vendor switching" to be a very bad idea. "zypper dup" was simply not designed for it.
Thanks Andrei, I'll chock it up to lessons-learned and find a better way to do a single repo dup. Here there were only 7 packages, so the copy and local install was a simple work around... But, I'll be back in the same boat when the openSUSE NVidia repo is finally updated and I need to switch packages back to that repo. What is the best way to do a single-repo dup in that case? Worst-case, I can just download the packages... -- David C. Rankin, J.D.,P.E.
On Wed, Aug 14, 2024 at 11:12 AM David C. Rankin <drankinatty@gmail.com> wrote:
But, I'll be back in the same boat when the openSUSE NVidia repo is finally updated and I need to switch packages back to that repo. What is the best way to do a single-repo dup in that case? Worst-case, I can just download the packages...
You could use YaST which IIRC offers "switch packages to this repository" or something like that. Or you could use the exact version zypper in package=version which will force a vendor switch.
On 8/14/24 3:20 AM, Andrei Borzenkov wrote:
You could use YaST which IIRC offers "switch packages to this repository" or something like that. Or you could use the exact version
zypper in package=version
which will force a vendor switch.
I've seen some option like that in Yast, but I've never tried it. The version string is another good idea. That's doable for 7 packages. I'm hoping the official rpms have package versions that would trigger their selection anyway. The version strings on the .rpm I got from Patrick didn't track those in the official NVidia repo, so there was no need for an --old-package option -- I think they were different enough that the solver didn't consider the packages from Patrick's repo the same as those in the official NVidia repo. That just added to the fun... -- David C. Rankin, J.D.,P.E.
On 8/14/24 3:02 AM, Andrei Borzenkov wrote:
Personally I consider using "zypper dup -r single-repository" as a "poor man's vendor switching" to be a very bad idea. "zypper dup" was simply not designed for it.
Andrei, Would "zypper dup --from single-repo" be a better way of duping to packages in a single repo. man-page suggests it is, or is this just another -r by another name? -- David C. Rankin, J.D.,P.E.
On Fri, Aug 16, 2024 at 1:48 AM David C. Rankin <drankinatty@gmail.com> wrote:
On 8/14/24 3:02 AM, Andrei Borzenkov wrote:
Personally I consider using "zypper dup -r single-repository" as a "poor man's vendor switching" to be a very bad idea. "zypper dup" was simply not designed for it.
Andrei,
Would "zypper dup --from single-repo" be a better way of duping to packages in a single repo. man-page suggests it is, or is this just another -r by another name?
E-h-h ... you do not believe or trust the manual page? It quite clearly describes the difference. I admit that I have not thought about it.
participants (2)
-
Andrei Borzenkov -
David C. Rankin