Arch Linux User Repository

thx @taziotoninzo

@simona Waiting for kachelaqa to properly fix up things, you can get rid of 'pacman<5.3' in PKGBUILD. Then if you makepkg (skipping checks), the most obvious issue is an implicit declaration of function ‘alpm_option_set_arch’. If you replace the corresponding lines (71, 418) in alpm.pyx with: int alpm_option_add_architecture(alpm_handle_t handle, const char arch) and: return alpm_option_add_architecture(handle, arch) then pkgbrowser builds and runs again. Does it work like before? Who knows?

of course, I'm sorry, I didn't mean to put any anxiety or pressure on you.

@simona Nothing is forcing you to update your system every day. Most users only update once a month or once a week. PkgBrowser will be updated when I find time to do it (certainly not today and maybe not this week).

Today pacman 6.0 was official and i must uninstall pkgbrowser....

@oech3 I highly doubt it, but you never know...

Is it possible to build with pacman 6.0.0-2 at Staging repo?

@mser Thanks for your interest. I don't really develop pkgbrowser any more except to fix bugs, so it's unlikely that I would ever consider adding support. I've been using PyQt since version 3 was first released and have never experienced any if the issues you mention - so it's very much a case of IIABDFI as far as I'm concerned.

@kachelaqa

Hydrus, for example, usually supports both (using said python-qtpy). There's a known issue right now when using python-pyqt5 because of an oversight from the Hydrus developer (which is why I've forced pyside2 as dependency for now), but other than that there haven't really been any problems.

This is actually what prompted me to ask if PkgBrowser could potentially also support both. I generally like the idea of giving users the the option to choose if there's two (or more) dependencies that can largely be used interchangeably without requiring too much additional development effort. This adds some flexibility; e.g., in this particular case, if python-pyqt5 or pyside2 wasn't compatible with a new version of Python yet or if a bug got introduced in either package, users could then possibly easily switch to the other and continue using PkgBrowser (without having to manually downgrade a package or using some other workaround).

Anyway, I also get your point and I can see how you wouldn't want to deal with potential bugs or issues that arose from supporting both.

Thanks for the quick reply and the great software!

@mser It's not just the lack of complete API compatibility. There are numerous undocumented internal and external behavioural differences, as well as a different set of potential bugs to work around. I doubt whether any abstraction layer could feasibly deal with them all.