Re: Clarification for package naming policy
On ചൊ, ജൂലൈ 12, 2022 at 7:40 വൈകു, Marc Dequènes
(duck) <duck@duckcorp.org> wrote:
Quack,
(sorry for the big lag)
On 2022-05-27 01:39, Daniel Leidert wrote:
What about a
Provides: ruby-deckar01-task-list
?
It already does that but apt search does not look at this field, so I
did not find it.
Ideally apt should look in Provides too. In javascript team, use of
Provides is very common. So I tend to use apt-file find often.
$ apt-file find deckar01
ruby-task-list: /usr/share/nodejs/deckar01-task_list/dist/task_list.js
ruby-task-list: /usr/share/nodejs/deckar01-task_list/package.json
ruby-task-list:
/usr/share/rubygems-integration/all/specifications/deckar01-task_list-2.3.1gemspec
Also aptitude show can list Provides
$ aptitude show ruby-deckar01-task-list
No candidate version found for ruby-deckar01-task-list
Package: ruby-deckar01-task-list
State: not a real package
Provided by: ruby-task-list (2.3.1-1)
I know these are not ideal, but it works now.
So now I guess I need to remove this new package but I still disagree
with the naming and I'm slightly fed up to have done this work for
nothing.
I wanted to raise the problem so that we do not hit such problem
again, especially if the original project happens to continue and
diverge, but it does not seem to bring much attention.
I think it should be case by case, sometimes there is only a single
reverse dependency as in this case and going via NEW when Provides can
actually solve the problem is a barrier as NEW queue takes an
unpredicatable amount of time and license review has already happened
once.
Well, thanks for your reply Daniel.
Reply to: