openSUSE / opi

OBS Package Installer (CLI)
GNU General Public License v3.0
244 stars 22 forks source link

opi installing package from wrong repo #115

Closed xpufx closed 1 year ago

xpufx commented 1 year ago
$ opi wezterm
1. wezterm
2. wezterm-debuginfo
3. wezterm-debugsource
4. wezterm-mux-server
5. wezterm-zsh-completion
6. wezterm-bash-completion
7. wezterm-fish-completion
8. wezterm-mux-server-debuginfo
Pick a number (0 to quit): 1
You have selected package name: wezterm
1. openSUSE:Factory +                        | 20221119.145034.49b9839f+ | x86_64
2. X11:terminals ?                           | 20221119.145034.49b9839f+ | x86_64
3. home:Dead_Mozay !                         | 20220624141144bd1b7c5d    | x86_64
4. home:xpufx !                              | 20221221.000000.72da5d1   | x86_64
Pick a number (0 to quit): 4
You have selected binary package: home:xpufx ! | 20221221.000000.72da5d1 | x86_64
BE CAREFUL! The package is from a personal repository and NOT reviewed by others.
You can ask the author to submit the package to development projects and openSUSE:Factory.
Learn more at https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  wezterm

1 new package to install.
Overall download size: 26.9 MiB. Already cached: 0 B. After the operation, additional 73.9 MiB will be used.
Continue? [y/n/v/...? shows all options] (y):
Retrieving package wezterm-20220624141144bd1b7c5d-1.27.x86_64                                                                                                           (1/1),  26.9 MiB ( 73.9 MiB unpacked)
Retrieving: wezterm-20220624141144bd1b7c5d-1.27.x86_64.rpm ..............................................................................................................................[done (416.0 KiB/s)]

Checking for file conflicts: ..........................................................................................................................................................................[done]
(1/1) Installing: wezterm-20220624141144bd1b7c5d-1.27.x86_64 ..........................................................................................................................................[done]
opi wezterm  4.97s user 0.78s system 7% cpu 1:18.00 total

$ zypper info wezterm
Loading repository data...
Reading installed packages...

Information for package wezterm:
--------------------------------
Repository     : home:Dead_Mozay
Name           : wezterm
Version        : 20220624141144bd1b7c5d-1.27
Arch           : x86_64
Vendor         : obs://build.opensuse.org/home:Dead_Mozay
Installed Size : 73.9 MiB
Installed      : Yes
Status         : up-to-date
Source package : wezterm-20220624141144bd1b7c5d-1.27.src
Upstream URL   : https://github.com/wez/wezterm
Summary        : A GPU-accelerated cross-platform terminal emulator and multiplexer
Description    :
    A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust

$

I am selecting package 4. home:xpufx but package 3. home:Dead_Mozay is being installed.

asdil12 commented 1 year ago

What does zypper lr -u print? I'm asking because I suspect that you still have the home:Dead_Mozay repo.

xpufx commented 1 year ago

I did have home:Dead_Mozay, yes. I thought I could have multiple repos enabled and use opi to pick where individual packages come from. Isn't it how opi works?

xpufx commented 1 year ago

I had some time to figure out what's happening by comparing regular zypper command line operation with what opi is doing. When I have both repos the other one is probably having precedence just by virtue of alphabetic order and this is how zypper works. However it looks like zypper can be told exactly which repo to use:

zypper in --from package

I thought maybe it might freak out about dependency packages not being in that repo but it seems to install them using the base system repos without a problem. I haven't looked at the code extensively yet to see if you use --from equivalent (or its alias --repo) at the install stage.

(I took a look: I think --from is not used 'if existing_repo' ) As a hack I tried to pass the 'uri' there instead of the repo alias and it worked as a quick test.

luc14n0 commented 1 year ago

Help me with my mental model please. In this case, did your repo get added to Zypper or not?

xpufx commented 1 year ago

Hi. zypper asks whether I want to add the repo as usual and I said yes to both repos in order to be able to test it in the scenario I originally had.

Please let me know if I misunderstood your question.

asdil12 commented 1 year ago

The odd thing is that opi actually calls zypper with the --from argument.

xpufx commented 1 year ago

Not here as far as I can tell: https://github.com/openSUSE/opi/blob/master/opi/__init__.py#L331

asdil12 commented 1 year ago

Then I will add a fix for that case.

xpufx commented 1 year ago

Confirmed working.

luc14n0 commented 1 year ago

Hi. zypper asks whether I want to add the repo as usual and I said yes to both repos in order to be able to test it in the scenario I originally had.

Please let me know if I misunderstood your question.

Thanks, that's it. I'm trying to understand that what's going on with opi/__inti.py too.

luc14n0 commented 1 year ago

From what I've understood reading this issue. Isn't installing from the repo being added the wanted behavior here, since home:Dead_Mozay and home:xpufx should yield different URIs?

If this change, that was made:

        existing_repo = get_enabled_repo_by_url(url)
        if existing_repo:
            # Install from existing repos (don't add a repo)
-           install_packages([name_with_arch])
+           print(f"Installing from existing repo '{existing_repo}'")
+           install_packages([name_with_arch], from_repo=existing_repo)
        else:
+           print(f"Adding repo '{project}'")
            add_repo(
                filename = repo_alias,
                name = project,

Works like my understood expectation here, yeah, something odd is going on. Any insights are welcomed.

luc14n0 commented 1 year ago

Excuse me @xpufx, could do you please expand on:

and I said yes to both repos in order to be able to test it in the scenario I originally had.

To both repos? Could you give the steps you used there?

asdil12 commented 1 year ago

As far as I know there is no code path where two repos are added in one opi call. The problem here was that there was still already another repo present from the last opi call and additionally there was the right repo added in a past opi call. The issue was that opi only enforced actually installing the rpm from the selected repo, when said repo was not already present. If it was already present, opi wouldn't care where the rpm came from during installation.

luc14n0 commented 1 year ago

Thank you for the explanation. That makes things clear for me now.