On 09/13/2018 06:43 PM, Mathieu Bridon wrote:
On Thu, 2018-09-13 at 18:17 +0200, Tomas Orsava wrote:
We'd like to propose a new functionality for dnf: When a user tries to install a package XYZ and dnf doesn't find it, dnf would recommend them alternative packages. These offered packages would advertise that they are an alternative for XYZ using a specially formatted Provides tag.
For example, packages `python2-requests` and `python3-requests` would both have the following tag:
Provides: alternative-for(python-requests) = %{version}-
%{release}
(Possibly via the already existing and widespread %python_provide macro in the Python case.)
And when the user would try to install `python-requests`, dnf would look for packages with the relevant Provides tag and display them:
# dnf install python-requests * There are following alternatives to this package:
python2-requests python3-requests No match for argument: python-requests Error: Unable to find a match
This would be very similar to an already existing functionality that searches for lowercase package names:
# dnf install python3-REQUESTS * Maybe you meant: python3-requests No match for argument: python3-REQUESTS Error: Unable to find a match
(That functionality is broken in some versions—RHBZ#1628514—so you might not see this result at the moment.)
What are your thoughts?
It's neat, but it doesn't help catch typos, which seems like the most probably case where I'd want such a feature.
How about instead of a scheme based on provides, just quickly check if a package has a "similar" name?
Basically extend the existing check for lowercase you mention.
Catching typos would be useful, and I'd certainly support that addition, but this doesn't really scratch the itch I'm trying to solve. We want to tell the user "these are exactly the alternatives available to you". Not guess, not rely on some typo resolution. We know what the alternatives are, here they are.
I've talked with people working on dnf and this looks like an easy mechanism to add, and it will be more reliable for the use cases it covers.
Tomas
$ git stats git: 'stats' is not a git command. See 'git --help'.
The most similar command is status
On Thu, Sep 13, 2018 at 12:58 PM Tomas Orsava torsava@redhat.com wrote:
On 09/13/2018 06:43 PM, Mathieu Bridon wrote:
On Thu, 2018-09-13 at 18:17 +0200, Tomas Orsava wrote:
We'd like to propose a new functionality for dnf: When a user tries to install a package XYZ and dnf doesn't find it, dnf would recommend them alternative packages. These offered packages would advertise that they are an alternative for XYZ using a specially formatted Provides tag.
For example, packages `python2-requests` and `python3-requests` would both have the following tag:
Provides: alternative-for(python-requests) = %{version}-
%{release}
(Possibly via the already existing and widespread %python_provide macro in the Python case.)
And when the user would try to install `python-requests`, dnf would look for packages with the relevant Provides tag and display them:
# dnf install python-requests * There are following alternatives to this package:
python2-requests python3-requests No match for argument: python-requests Error: Unable to find a match
This would be very similar to an already existing functionality that searches for lowercase package names:
# dnf install python3-REQUESTS * Maybe you meant: python3-requests No match for argument: python3-REQUESTS Error: Unable to find a match
(That functionality is broken in some versions—RHBZ#1628514—so you might not see this result at the moment.)
What are your thoughts?
It's neat, but it doesn't help catch typos, which seems like the most probably case where I'd want such a feature.
How about instead of a scheme based on provides, just quickly check if a package has a "similar" name?
Basically extend the existing check for lowercase you mention.
Catching typos would be useful, and I'd certainly support that addition, but this doesn't really scratch the itch I'm trying to solve. We want to tell the user "these are exactly the alternatives available to you". Not guess, not rely on some typo resolution. We know what the alternatives are, here they are.
I've talked with people working on dnf and this looks like an easy mechanism to add, and it will be more reliable for the use cases it covers.
I personally am not sure whether this is a good idea, but it definitely should only be implemented as a plugin.
My feeling about this is that we should just specify the flag release where we transition python-* to python3-* packages using %python_provide.
Anything else is more work for very little benefit.
-- 真実はいつも一つ!/ Always, there's only one truth!
packaging@lists.fedoraproject.org