Bug 2221233

Later, I have realized that on my older system, I used to have `skip_if_unavailable=True` in my dnf.conf, which would probably help with this. Nevertheless, I am not sure why this is actually not enabled by default. IMHO, missing repository might end up in not available package or broken dependencies, but I can't see why it should be fatal error.

Hi, in general, dnf must load repository metadata even when installing a local package in case the package has dependencies that are available in the repositories. And dnf fails if it fails to load the metadata of a repository with `skip_if_unavailable=false`.

The default is false, because it's safer from a security standpoint. The only change in dnf5 is that we no longer ship configuration override to Fedora, but there is a plan to add drop-in configuration directory for other packages to provide the override, if the distribution desires it. There is still a discussion around this, see bug 2216205. I'm closing this as a duplicate.

*** This bug has been marked as a duplicate of bug 2216205 ***

(In reply to Pavla Kratochvilova from comment #2)
> Hi, in general, dnf must load repository metadata even when installing a
> local package in case the package has dependencies that are available in the
> repositories.

With all due respect, I don't think this is sensitive behavior. I have asked DNF to explicitly install "/run/media/vondruch/8715-3993/iwlwifi-mvm-firmware-20230625-151.fc39.noarch.rpm". But instead DNF looking into that package and continuing from there, DNF ignores my request and cares about some metadata. That is not right and that is not user friendly. If there are some required dependencies and DNF cannot get them, DNF knows what to do. Any amount of additional repositories/metadata cannot ensure that the dependencies will be provided. More often then not, if I want to install something from command line, I am ready and I have to also install all the necessary dependencies specifying them on command line.

> And dnf fails if it fails to load the metadata of a repository
> with `skip_if_unavailable=false`.
> 
> The default is false, because it's safer from a security standpoint.

If you want to argue about security, then I am afraid that downloading some data from the internet instead of using the data provided on command line is hardly more secure.

> With all due respect, I don't think this is sensitive behavior. I have asked DNF to explicitly install "/run/media/vondruch/8715-3993/iwlwifi-mvm-firmware-20230625-151.fc39.noarch.rpm". But instead DNF looking into that package and continuing from there, DNF ignores my request and cares about some metadata. That is not right and that is not user friendly. If there are some required dependencies and DNF cannot get them, DNF knows what to do.

If dnf first considered only the command line packages, and then loaded the metadata only if it failed to resolve dependencies, it would mean unnecessary duplicit resolvement, more complicated behavior and it couldn't take reverse dependencies into account.

> Any amount of additional repositories/metadata cannot ensure that the dependencies will be provided. More often then not, if I want to install something from command line, I am ready and I have to also install all the necessary dependencies specifying them on command line.
> If you want to argue about security, then I am afraid that downloading some data from the internet instead of using the data provided on command line is hardly more secure.

I understand this is your use case. If you want to have complete control over the operation and don't want to care about repositories at all, there is also an option to use rpm in this case.

(In reply to Pavla Kratochvilova from comment #4)
> > With all due respect, I don't think this is sensitive behavior. I have asked DNF to explicitly install "/run/media/vondruch/8715-3993/iwlwifi-mvm-firmware-20230625-151.fc39.noarch.rpm". But instead DNF looking into that package and continuing from there, DNF ignores my request and cares about some metadata. That is not right and that is not user friendly. If there are some required dependencies and DNF cannot get them, DNF knows what to do.
> 
> If dnf first considered only the command line packages, and then loaded the
> metadata only if it failed to resolve dependencies, it would mean
> unnecessary duplicit resolvement,

It would not be such a big deal, would it be? I guess that resolving dependencies of one or a few packages specified on the command line can't hurt.

> more complicated behavior and it couldn't
> take reverse dependencies into account.
> 
> > Any amount of additional repositories/metadata cannot ensure that the dependencies will be provided. More often then not, if I want to install something from command line, I am ready and I have to also install all the necessary dependencies specifying them on command line.
> > If you want to argue about security, then I am afraid that downloading some data from the internet instead of using the data provided on command line is hardly more secure.
> 
> I understand this is your use case. If you want to have complete control
> over the operation and don't want to care about repositories at all, there
> is also an option to use rpm in this case.

Please consider my situation. This was not about what I want. I wanted to have functional system but it was not. I tried to recover it but DNF was not helpful at all. Instead you send me towards RPM, which in long run cannot be beneficial, because then DNF does not know about such package.

DNF knows which packages are local.
How about if the list of local packages is not empty and there are no other package specs that might match with any remote packages, throw the local packages into a transaction prior loading repos. If it succeedes, we have what we wanted. If it fails, load repos and retry.

The only disadvantage is that weak deps from remote repos wouldn't get installed.

It's definitely worth trying. We don't want anyone using RPM directly, maybe with the exception of fixing an utterly broken installation.