Skip to main content
Topic: pacman 5.2.0 has updated libalpm to 12.0.0 but octopi/yaourt need 11.0 (Read 2049 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

pacman 5.2.0 has updated libalpm to 12.0.0 but octopi/yaourt need 11.0

This seems to be a rehash of https://forum.artixlinux.org/index.php/topic,669.0.html from a bit over a year ago.  I'll see if I can play with the PKGBUILD, but I'm not sure how quickly I can get there, in case it's actually (hopefully) a trivial change for anyone else.

Re: pacman 5.2.0 has updated libalpm to 12.0.0 but octopi/yaourt need 11.0

Reply #1
There is an updated alpm_octopi_utils and octopi in gremlins.

However, the new (unreleased) octopi-0.10 from git has some issues, hence still gremlins, but it will make the notifier work again at least.


Re: pacman 5.2.0 has updated libalpm to 12.0.0 but octopi/yaourt need 11.0

Reply #2
On my desktop  without gremlins, I suppose I'll just have to wait.  On my laptop with gremlins, I've already got those newer versions.  Octopi-notifier seems to work fine, but octopi (Version: 0.10.0 (dev) - Qt 5.13.1) now starts with a popup "Pacman Database is missing!  You may need to synchronize database!" and doesn't show any packages at all.  Pacman itself seems to be working just fine.  I have no idea if that is related, or just some local configuration problem, although it used to work ok.

Re: pacman 5.2.0 has updated libalpm to 12.0.0 but octopi/yaourt need 11.0

Reply #3
About yaourt.
This project was discontinued and is not supported, please use another AUR helper.

Recently we removed yaourt from Artix repositories.

Re: pacman 5.2.0 has updated libalpm to 12.0.0 but octopi/yaourt need 11.0

Reply #4
Oh well, I've used yaourt for years, and gotten used to it.  I suppose I'll find a replacement.

Shouldn't it be safe to extract just libalpm.so.11 from a previous pacman package and copy it to /usr/lib without interfering with the .12 versions, and the old octopi and octopi-notifier will at least still work until the new versions are stable.

Re: pacman 5.2.0 has updated libalpm to 12.0.0 but octopi/yaourt need 11.0

Reply #5
https://aur.archlinux.org/packages/octopi/

$ yay -Sa octopi alpm_octopi_utils
(must be -Sa, -S installs repo version)
Then ignore octopi in /etc/pacman.conf or it tries to upgrade itself immediately.
IgnorePkg   = octopi

It built fine.
But I couldn't install anything as on xfce gksu wouldn't work, I could sync the db and select packages by just hitting cancel without a pw every time it showed the gksu window. gksu is deprecated anyway, only found in the AUR, and kdesu didn't work either although I only tried briefly.
If you had octopi working before it would probably work, I don't normally use any apps needing graphical authentication anyway. pkexec octopi still wouldn't work as it wanted to authenticate itself. (I could do pkexec thunar but not gksu thunar so it was my gksu issues stopping things, not octopi itself.)

Re: pacman 5.2.0 has updated libalpm to 12.0.0 but octopi/yaourt need 11.0

Reply #6
Oh well, I've used yaourt for years, and gotten used to it.  I suppose I'll find a replacement.

Shouldn't it be safe to extract just libalpm.so.11 from a previous pacman package and copy it to /usr/lib without interfering with the .12 versions, and the old octopi and octopi-notifier will at least still work until the new versions are stable.


what might be the favorite recommented replacement to yaout?

Re: pacman 5.2.0 has updated libalpm to 12.0.0 but octopi/yaourt need 11.0

Reply #7
I beg to differ; runit hasn't received an upstream update since 2014 not because it's unmaintained but because it's considered feature-complete and sufficiently bug-free by its author.

Same thing applies to yaourt: it's the reference pacman and AUR helper and there's a reason for that. Just update package-query to 1.10 and everything works again like a charm. Or wait until tomorrow night when I'll (try to) push it in the repos.

 

Re: pacman 5.2.0 has updated libalpm to 12.0.0 but octopi/yaourt need 11.0

Reply #8
I beg to differ; runit hasn't received an upstream update since 2014 not because it's unmaintained but because it's considered feature-complete and sufficiently bug-free by its author.

Same thing applies to yaourt: it's the reference pacman and AUR helper and there's a reason for that. Just update package-query to 1.10 and everything works again like a charm. Or wait until tomorrow night when I'll (try to) push it in the repos.


I lost you here?  What is this in reference to?  Do we have a solution to octopi yet and doesn't octopi use yaourt in the background :(

Re: pacman 5.2.0 has updated libalpm to 12.0.0 but octopi/yaourt need 11.0

Reply #9
and doesn't octopi use yaourt in the background :(

From Octopi Redme:
Quote
How to enable AUR support (that "alien" icon at toolbar)
To enable AUR support, you'll need to install yaourt, pacaur, pikaur or trizen in your system.

Re: pacman 5.2.0 has updated libalpm to 12.0.0 but octopi/yaourt need 11.0

Reply #10
The majority of the Artix devs are against having any pacman/makepkg/AUR helpers in our repos, and for good reasons.

Consider having yaourtix, trizen, octopi and pamac an exuberantly luxurious courtesy to spoil our users, but use them at your own risk.

Re: pacman 5.2.0 has updated libalpm to 12.0.0 but octopi/yaourt need 11.0

Reply #11
The majority of the Artix devs are against having any pacman/makepkg/AUR helpers in our repos, and for good reasons.

AURs by definition need to be used at your own risk, but you really don't want to be responsible for the vast database of options in the AURs, many of which really make the  OS usable.

For example, I use windowmaker.  There is no reason for YOU to maintain that, or even Arch.  If I have trouble with it, I have to go the the AUR maintainer.  But I do need to update it from time to time.  It would be unfair for users to put the burden of all that on you.  There needs to be a community.  One should not expect to toss the entire burden on you from soup to nuts.  I am very happy you provide a working skelaton of the OS to hang fruit on.