How to user-fix an app package calling obsolete dependencies

[goodbot]

I'm a user trying to build and install an app. When I run pacman, it finds my app, it identifies 3 required dependency files (note: each file with an explicitly declared version #)... when it proceeds to download the files, however, pacman bombs out reporting that it can't find these particular dependency files. When I research what's on the mirror I'm pointing to, I see that 2 of these 3 files are more recent version #s. Is this something I can handle/fix down here in Userland... or do I need to get the package developer/maintainer involved?

[WarheadsSE]

You packager should not be binding to explicit versions without a very good reason. Inform them that newer versions exist.

[goodbot]

Hi WarheadsSE:

I got in touch with the Packager... who I thought was the Packager (the guy who's created the program widely ported to other platforms)... but... it turns out that he himself doesn't package anything for this Arch/Arm environment... He asserts that the Packager is someone unknown to him over here in this community...

I can't find any reference anywhere to anyone other than that creator/coder of the app (who knows nothing about Arch/Arm)...

Sooo... some beneficent friendly soul over here took it upon him/her self to port this app here... but... there's no apparent trace-back to this person... no apparent way to easily/readily fix this immediate issue here of mine?

I probably don't need to get into a dialogue with the "local porter" of this app... I just need access to their (faulty/obsolete) build package... Is there a way in pacman to simply dl the build package (config) file without executing it? I'll make the necessary changes in that file (or config file) myself...

I'm looking for the shortest route to what I need to do here... I just need to figure out the simple chore of updating the build config values myself... how do I get to that file to change this stuff myself?

[moonman]

What is the package? Its either in our github or abs.
If abs, install it, run abs --update and find pkgbuilds under /var/abs

Research abs, makepkg, PKGBUILD. Everything is in archwiki

[goodbot]

Moonman:

Thanks for this seemingly useful heads-up... I'll invest the time to follow your suggestions asa I awake a few hours from now (I'm asleep right now... my system is handling my business at this time)...

goodbot

[goodbot]

Moonman:

Following your good advice, I sought to start things off on my local RPi/arm6 box by installing abs. Is it odd that with this package also I ran into pretty much the exact same error:

$this->bbcode_second_pass_code('', '[root@alarmpi ~]# pacman -S abs
resolving dependencies...
looking for inter-conflicts...

Packages (2): rsync-3.0.9-6 abs-2.4.4-1

Total Download Size: 0.23 MiB
Total Installed Size: 0.59 MiB

:: Proceed with installation? [Y/n] Y
:: Retrieving packages ...
error: failed retrieving file 'rsync-3.0.9-6-armv6h.pkg.tar.xz' from us.mirror.archlinuxarm.org : The requested URL returned error: 404 Not Found
warning: failed to retrieve some files
abs-2.4.4-1-armv6h 7.9 KiB 3.86M/s 00:00 [######################] 100%
error: failed to commit transaction (unexpected error)
Errors occurred, no packages were upgraded.
')

When the contents of the used mirror site are inspected, we find a more up-to-date version of the rsync file ("http://us.mirror.archlinuxarm.org/armv6h/extra/rsync-3.1.0-1-armv6h.pkg.tar.xz"). So, yet again it appears that my attempted installation of a package (abs here now) is bombing because of this explicit declaration to an obsolete dependency package.

One plus in this exercise for me, however, is that I've discovered (embedded in one or another files comments) contact info for responsible coders or maintainers. I'll try contacting these fellows separately.

Another oddity I've discovered in perusing the code in the abs-2.4.4-1-armv6h package I was able to successfully retrieve (because of the exact version match)... within the (intended to be installed) "/etc/abs.conf" file are the lines:

$this->bbcode_second_pass_code('', '
#
# The architecture to fetch abs for
# Either i686 or x86_64
#
ARCH="i686"

')

So... if the attempted "pacman -S abs" had actually worked for me, it would have afterwards been my responsibility to hunt down this explicitly declared config mismatch and change 'ARCH="i686" ' to "ARCH="armv6h" ' ? Is this declared mismatch a bug here... or is this generally what everyone usually needs to do to successfully install versions of packages for platforms other than i686 ?

In any case, I'm following your recommendation and reading through the wiki entries on the list of requisite topics I need to know to eventually fix these errors by myself. So... now, before I figure out how to fix the (esoteric) bgfminer package (the initial one that bombed out on me), I'll need to first figure out how to fix this (popular, common) abs package... correct?

Hopefully I can get some help with this by reaching out to the contact in the comment lines.

[moonman]

You need to add the -y to pacman to sync with the repo. If you do a full update i'm pretty sure your problems will go away
Pacman -Suy

[WarheadsSE]

ABS: no, not really. We do use their i686 source trees, and makepkg -A
Anything changed is in GitHub.

[goodbot]

The abs-package developer/maintainer aaron@archlinux.org provided me the succinct solution to both of my "obsolete dependency" errors: I needed to refresh my local pacman.db with the latest version of the master package list via the command "pacman -Sy"...

After doing this, both packages that had previously failed now installed (seemingly) correctly...

So that's a good command to remember and to use... probably before trying to install any new packages.

Thank you Aaron!

I'm learning...

[goodbot]

WarheadsSE:

So after my successful installation of the abs package, sure enough I'm sitting with an /etc/abs.conf files declaring ARCH='i686"...

Your reply is a bit uncertain... should I change this (and other such anomalies I can find) manually myself... or can I disregard this because some follow-on routine will adjust/fix this value as necessary when called down the line?