Bug 1537961

Thanks for your suggestions.

(In reply to Jaroslav Škarvada from comment #0)
> I think it should take DNF repos by default if no option is given, i.e.:
> $ rpmdeplint check ./grep-3.1-3.fc28.x86_64.rpm 
> Problems with dependency set:
> nothing provides /bin/sh needed by grep-3.1-3.fc28.x86_64

I made this case report an error, with a message indicating you should pass --repo or --repos-from-system. I really don't want to just default to --repos-from-system because I think the user should think carefully what repos they are running the test against. The wrong set of repos can easily invalidate the results.

https://gerrit.beaker-project.org/6009

> It would be great to have DNF compatible options like --enablerepo /
> --disablerepo to enable/disable DNF configured repos.

The --disablerepo/--enablerepo options in Yum/DNF have surprisingly complicated semantics, because they have to be processed in order and do glob matching... I would rather not reimplement that in rpmdeplint and maintain it forever.

Do you think this is really necessary?

> It would be nice for the rpmdeplint to automatically skip non-available
> repos in this mode (or at least to have option to do it), e.g.:
> $ rpmdeplint check-sat --repos-from-system ./grep-3.1-3.fc28.x86_64.rpm 
> Failed to download repodata for Repo(repo_name='fedora-chromium-stable',
> baseurl='http://repos.fedorapeople.org/repos/spot/chromium-stable/fedora-26/
> x86_64/'): Cannot download repomd.xml: Cannot download repodata/repomd.xml:
> All mirrors were tried
> 
> I have enabled some RHEL internal repos (the above error is not this case,
> but it's the same kind of error), which are not publicly available and when
> doing the Fedora update and not being on the RHEL VPN, it would be handy for
> the tool to work (like DNF) without other tweaks.

I have made it obey skip_if_unavailable=1 when using --repos-from-system.

https://gerrit.beaker-project.org/6011

> I would like to see -C, --cacheonly like DNF has to run entirely from the
> cache.

This one is tricky. Rpmdeplint does not cache the repomd.xml, it fetches that every time to ensure it is always using the latest repodata. (The other repodata files mentioned in repomd.xml *are* cached.) But that means I can't implement a --cacheonly mode because it has no record of which repodata files came from which repo URLs.

I could have it do something like, rummage around in /var/cache/dnf looking for a cache for the same named repo (and just ignore the URL you gave it and assume that it's talking about the same repo) but it seems like a lot of extra code in rpmdeplint for very little benefit.

Bear in mind that if you want to do a hacky rpmdeplint run like that, you already can just point it at dnf's local cache by doing something like:

    rpmdeplint --repo=rawhide,/var/cache/dnf/rawhide-2d95c80a1fa0a67d/ ...

(In reply to Dan Callaghan from comment #1)
> Thanks for your suggestions.
> 
> (In reply to Jaroslav Škarvada from comment #0)
> > I think it should take DNF repos by default if no option is given, i.e.:
> > $ rpmdeplint check ./grep-3.1-3.fc28.x86_64.rpm 
> > Problems with dependency set:
> > nothing provides /bin/sh needed by grep-3.1-3.fc28.x86_64
> 
> I made this case report an error, with a message indicating you should pass
> --repo or --repos-from-system. I really don't want to just default to
> --repos-from-system because I think the user should think carefully what
> repos they are running the test against. The wrong set of repos can easily
> invalidate the results.
> 
> https://gerrit.beaker-project.org/6009
>
Thanks. I am OK with it. Could we also have short option for it? The --repos-from-system is quite long.

> > It would be great to have DNF compatible options like --enablerepo /
> > --disablerepo to enable/disable DNF configured repos.
> 
> The --disablerepo/--enablerepo options in Yum/DNF have surprisingly
> complicated semantics, because they have to be processed in order and do
> glob matching... I would rather not reimplement that in rpmdeplint and
> maintain it forever.
> 
> Do you think this is really necessary?
>
Thanks for info, I wasn't aware of the implementation details. So it's OK as is.
 
> > It would be nice for the rpmdeplint to automatically skip non-available
> > repos in this mode (or at least to have option to do it), e.g.:
> > $ rpmdeplint check-sat --repos-from-system ./grep-3.1-3.fc28.x86_64.rpm 
> > Failed to download repodata for Repo(repo_name='fedora-chromium-stable',
> > baseurl='http://repos.fedorapeople.org/repos/spot/chromium-stable/fedora-26/
> > x86_64/'): Cannot download repomd.xml: Cannot download repodata/repomd.xml:
> > All mirrors were tried
> > 
> > I have enabled some RHEL internal repos (the above error is not this case,
> > but it's the same kind of error), which are not publicly available and when
> > doing the Fedora update and not being on the RHEL VPN, it would be handy for
> > the tool to work (like DNF) without other tweaks.
> 
> I have made it obey skip_if_unavailable=1 when using --repos-from-system.
> 
> https://gerrit.beaker-project.org/6011
> 
Great.

> > I would like to see -C, --cacheonly like DNF has to run entirely from the
> > cache.
> 
> This one is tricky. Rpmdeplint does not cache the repomd.xml, it fetches
> that every time to ensure it is always using the latest repodata. (The other
> repodata files mentioned in repomd.xml *are* cached.) But that means I can't
> implement a --cacheonly mode because it has no record of which repodata
> files came from which repo URLs.
> 
> I could have it do something like, rummage around in /var/cache/dnf looking
> for a cache for the same named repo (and just ignore the URL you gave it and
> assume that it's talking about the same repo) but it seems like a lot of
> extra code in rpmdeplint for very little benefit.
> 
> Bear in mind that if you want to do a hacky rpmdeplint run like that, you
> already can just point it at dnf's local cache by doing something like:
> 
>     rpmdeplint --repo=rawhide,/var/cache/dnf/rawhide-2d95c80a1fa0a67d/ ...

OK.

Thanks for the feedback.

(In reply to Jaroslav Škarvada from comment #2)
> Thanks. I am OK with it. Could we also have short option for it? The
> --repos-from-system is quite long.

Sure. I personally dislike short options because I can never remember what every single command's single-letter options mean. But I have no objection to adding them if you want to use them.

https://gerrit.beaker-project.org/6018

(In reply to Dan Callaghan from comment #3)
> Thanks for the feedback.
> 
> (In reply to Jaroslav Škarvada from comment #2)
> > Thanks. I am OK with it. Could we also have short option for it? The
> > --repos-from-system is quite long.
> 
> Sure. I personally dislike short options because I can never remember what
> every single command's single-letter options mean. But I have no objection
> to adding them if you want to use them.
> 
> https://gerrit.beaker-project.org/6018

Great, thanks.

FEDORA-2023-a965252f36 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a965252f36

FEDORA-2023-a965252f36 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-a965252f36`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-a965252f36

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-a965252f36 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.