pikaur Resolving indirect AUR dependencies (via `Provides` field)

Hey!

Trying to install ros-indigo-desktop-full (https://aur.archlinux.org/packages/ros-indigo-desktop-full) yields that python2-catkin-pkg cannot be found in AUR and hence ros-indigo-desktop-full cannot be installed.

Two things:

It would be nice if pikaur would show that the missing dep is a dep of ros-indigo-catkin
It actually is possible to know for pikaur that python2-catkin-pkg is being provided by python2-catkin_pkg since it's being listed explicitly in other packages of the dependency chain, hence it should be possible to solve the dependency chain for ros-indigo-desktop-full all in all

Mar 03 '18 20:03 polygamma

the thing is what search in AUR's rpc is not indexing Provides field so the only thing which i can do here -- get the full package list from AUR (like in -Ss without args) and next search through local 'mirror' of AUR db for such packages

but it takes about half minute, so mb before going to that type of search to prompt user for confirmation (like Package not found in AUR. Try to sync AUR locally to analyze 'Provides' sections of the packages?)

Mar 03 '18 21:03 actionless

Do any of you two know PHP? Sounds easier to file a patch to aurweb than come up with a good workaround here :smile:

https://bugs.archlinux.org/task/49090

Also what is your definition of "local mirror"? Do you retrieve packages.gz to query the AUR for all of them and merge the output somehow? IDK...

Mar 03 '18 22:03 AladW

i don't know php but i think i can add to RPC one more filter criteria, as name and name-desc as it have now to have also either provides or name-desc-provides (probably someone else should come up with a better name )

Mar 03 '18 22:03 actionless

i didn't noticed your edits on the original comment:

regarding local mirror, yes, see here: https://github.com/actionless/pikaur/blob/master/pikaur/aur.py#L306-L310

Mar 04 '18 04:03 actionless

@actionless Reference: https://github.com/AladW/aurutils/issues/10#issuecomment-370270445

The first part explains how aurman fetches packages and thus gets the needed information. May be interesting for you.

Mar 04 '18 22:03 polygamma

@AladW i had a moment to have a look on https://git.archlinux.org/aurweb.git/tree/web/lib/aurjson.class.php it doesn't look complicated, what is the procedure to submit a patch?

Mar 05 '18 02:03 actionless

or alternative approach to fixing that on AUR RPC side could be when searching by name match not only Name field but also Provides field

(but that should make search by name slower)

Mar 05 '18 05:03 actionless

@actionless the procedure is to send your patch to aur-dev where it can be merged after discussion. If you haven't used git send-email before, see https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/

Mar 05 '18 14:03 AladW

so i can't start a discussion topic / send patch without subscribing to the whole mail list?

Mar 05 '18 14:03 actionless

I don't recall if you have to be actually subscribed to send messages. If you do and you don't want to recieve other topics, you can disable recieving them in the mailman settings.

Mar 05 '18 14:03 AladW

ok, i'll try doing that tonight or so

Mar 05 '18 14:03 actionless

@AladW how do you think which of the approaches will be more acceptable:

adding name-desc-provides filter
adding provides filter
when searching by name match not only Name field but also Provides field
mb smth else?

Mar 06 '18 13:03 actionless

Personally I would prefer the third option, since I'm not sure what the benefits of an additional filter over a transparent approach are. I don't speak for the AUR development team though, so I'd propose these options on aur-dev as well. (the list is equally suited for discussion and posting of patches)

Mar 06 '18 15:03 AladW

@AladW i've submitted a message there but it didn't appeared here: https://lists.archlinux.org/pipermail/aur-dev/2018-March/date.html

could it be because my e-mail address is not subscribed to the mail list?

Mar 07 '18 18:03 actionless

Possible, you should have had a rejection mail in that case. Try subscribing then posting it (as mentioned, you can opt-out to receive messages from the list while still being subscribed)

Mar 07 '18 19:03 AladW

i haven't received rejection neither, but i'll try to subscribe and send the message again

Mar 07 '18 22:03 actionless

oh, or i can just parse AUR html web page which lists all the package alternatives :dancing_women:

Mar 07 '18 23:03 actionless

...please don't.

Mar 08 '18 00:03 AladW

@AladW see last message from Florian in the mail list -- such kind of control freaks is the reason why i didn't wanted to touch the mail list even with a long stick

Mar 08 '18 12:03 actionless

You shouldnt take it personally - the Arch mailing lists have a long history with email issues so people will remind you immediately. Anyway as you have may have noticed there's a positive response to the proposed changes so it's worthwhile to continue working on them. :smiley:

Mar 08 '18 13:03 AladW

don't worry, i'm not giving up ;-)

just mentioned why i so wanted to avoid that initially

Mar 08 '18 13:03 actionless

There are provides problems too when pikaur try to delete the make dependencies after finished making a package: screenshot_20180308_144903 (here python-distribute is provides by python-setuptools)

Mar 08 '18 19:03 XavierCLL

@XavierCLL could you check this again with the latest git version of pikaur?

Mar 08 '18 20:03 actionless

not yet, same issue using Pikaur 0.8+19+g094ee87

Mar 08 '18 20:03 XavierCLL

@XavierCLL pushed more fixes

Mar 08 '18 21:03 actionless

perfect, the last commit fixed the problem, thanks @actionless

Mar 08 '18 21:03 XavierCLL

@actionless, I've looked at the following patch: https://transfer.sh/L3H4Z/0001-feat-rpc-return-providers-packages-when-querying-by-.patch

I think it's actually a very bad idea to alter the existing name and name-desc fields. People are already working with that, and if you change it, many things might break, since you are changing what those fields do. Everybody, who is working with AurJson needs to change existing code, to adapt to the new usage of the fields. Such API changes should really never, ever happen.

Mar 13 '18 14:03 polygamma

i did proposed another alternatives but this one was chosen, feel free to file a patch implementing that in an other way

Mar 13 '18 15:03 actionless

Simple solution: bump the RPC version to 6. People who want the old API can keep using 5.

Mar 13 '18 15:03 AladW

What about adding this to info? info allows multiple arguments, so say a package you're fetching the dependencies for has 10 AUR dependencies. Before you would just do 1 info request with those 10 packages. Now you would have to do an individual search request for every dependency then get info from then. Which brings the request count up to 11.

Not to mention search is for, well searching. It does not look for exact names. So when you have the dependency foo and you want to find packages that also provide foo after you preform the search on the rpc you would have to check each package to see if they actually provide foo, or just happen to have a similar name.

I think this does belong in name and name-desc for -Ss type searching but for actual dependency resolving this should also also be added to info.

Mar 13 '18 16:03 Morganamilo

pikaur pikaur copied to clipboard

Resolving indirect AUR dependencies (via `Provides` field)

pikaur
pikaur copied to clipboard