On Thu, Sep 13, 2018 at 12:58 PM Tomas Orsava <torsava@xxxxxxxxxx> 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 mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
