Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: lib32-libcap depends on non-existing libcap=2.67 (system/libcap is ver. 2.68). (Read 823 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

lib32-libcap depends on non-existing libcap=2.67 (system/libcap is ver. 2.68).

lib32/lib32-libcap is currently at version 2.67-1 and depends on libcap=2.67, 
system/libcap is currently at version 2.68-1.

System upgrade fails with
Code: [Select]
:: installing libcap (2.68-1) breaks dependency 'libcap=2.67' required by lib32-libcap
.

Regards!

Re: lib32-libcap depends on non-existing libcap=2.67 (system/libcap is ver. 2.68).

Reply #1 –
Code: [Select]
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing libcap (2.68-1) breaks dependency 'libcap=2.67' required by lib32-libcap

me too
Cat Herders of Linux

Re: lib32-libcap depends on non-existing libcap=2.67 (system/libcap is ver. 2.68).

Reply #2 –
If you are in a rush it's in lib32-gremlins.
Code: [Select]
sudo pacman -U https://mirrors.dotsrc.org/artix-linux/repos/lib32-gremlins/os/x86_64/lib32-libcap-2.68-1-x86_64.pkg.tar.zst
 

Re: lib32-libcap depends on non-existing libcap=2.67 (system/libcap is ver. 2.68).

Reply #3 –
Quote from: gripped – on
If you are in a rush it's in lib32-gremlins.
Code: [Select]
sudo pacman -U https://mirrors.dotsrc.org/artix-linux/repos/lib32-gremlins/os/x86_64/lib32-libcap-2.68-1-x86_64.pkg.tar.zst

Thanks for that, but this is again a workaround and does not solve the unterlying problem of Artix repositories getting inconsistent quite often.

I can also just use Arch' multilib/lib32-libcap, since that is already updated ...

Re: lib32-libcap depends on non-existing libcap=2.67 (system/libcap is ver. 2.68).

Reply #4 –
Quote from: dreieck – on
Thanks for that, but this is again a workaround and does not solve the unterlying problem of Artix repositories getting inconsistent quite often.
Volunteer to be a dev then I guess ? In a perfect world this would never happen. The reality is that it does. Worse for those who are unable to fix these sort of problems (not stating you are in this set) are updates that break programs. In this case it seems it's just blocking an update, it will get sorted, and it's rare that a system update is essential. It can generally wait.
Quote
I can also just use Arch' multilib/lib32-libcap, since that is already updated ...
You can.
I may be remembering through rose tinted glasses but I think there were less of these issues when Artix only included packages in it's own repos that were strictly necessary to be altered to remove systemd. Everything else came from the Arch repos which were of course always enabled.

I preferred it like that. I would prefer it if it was still like that. But it isn't. It's not a big deal for me at all. Just a personally preference which may well be based on a lack of knowledge of the underlying issues?
I'm sure there were some reasons given at the time of the change but I don't remember them.

Would I recommend Artix to a new Linux user? No.
Would I recommend Artix to someone who has used Linux for quite a while but doesn't understand Arch and Pacman? No (with caveats).
Do I think Artix is the best distribution for my wants and needs? Without a doubt.

If it was down to me (it clearly isn't and I don't want it to be) there would be no iso's bar the base iso.
Then there would be far less clueless people (no offence intended to the clueless!) asking clueless questions because their system broke and they have absolutely no idea how to fix it.

Arch was, imho, originally a distribution for Linux users who, at the very least, could follow the instructions on the Arch wiki and build the OS from the ground up using pacstrap.

Times change. The barrier to entry is almost non existent now.

But to get back to Artix the way I see it is the devs give up their free time providing a systemd free version of Arch. No mean feat. And they should be congratulated that there are as few problems as do occur rather than be slightly berated for those that do.
I know I wouldn't want the role.

Of course i expect there's always room for improvement but I'm sure they don't break anything on purpose.

Re: lib32-libcap depends on non-existing libcap=2.67 (system/libcap is ver. 2.68).

Reply #5 –
Hi all. Subj.

Code: [Select]
# pactree -rd3 lib32-libcap
lib32-libcap
├─lib32-elogind
│ └─lib32-dbus
│   ├─lib32-libpcap
│   ├─lib32-libpulse
│   └─lib32-pipewire
└─pinentry
  └─gnupg
    ├─gpgme
    ├─pacman
    └─thunderbird

Re: lib32-libcap depends on non-existing libcap=2.67 (system/libcap is ver. 2.68).

Reply #6 –
I am never in a hurry.  I update when I see updates available.i think devs might be in a rush sometimes to push packages to the repos.  I don't appreciate being talked down to in forums when I report something is wonky.  If it's wonky, devs need to know.  This kind of talk above is just dividing the community.
Cat Herders of Linux

Re: lib32-libcap depends on non-existing libcap=2.67 (system/libcap is ver. 2.68).

Reply #7 –
lib32-libcap-2.68 has been moved from [lib32-gremlins] to [lib32]. Wait for your mirrors to sync.

Re: lib32-libcap depends on non-existing libcap=2.67 (system/libcap is ver. 2.68).

Reply #8 –
TY for all your hard work
Cat Herders of Linux

Appreciation!

Reply #9 –
Quote from: gripped – on
And they should be congratulated

OK, I do make it here explicitly now:

:green_heart: Many thanks and appreciation from me for the people who keep Artix up :thumbup: :tada:!

When I critisise something, I don't critisise the people, but some very specific issue. It's totally fine when there is no capacity to make those issues less frequent, but I might continue critisising it then each time ;-). OK, and now I think I will also start to show general appreciation for the work, too.

I still think (if this is wrong, please explain me) that this kind of issues like here can be solved programmatically (by recursively checking all dependencies in both directions and block a push of new versions if the check does not pass), but that neads something at the infrastructure level, and I totally can understand when people do not want to take that work.

Regards!

Re: lib32-libcap depends on non-existing libcap=2.67 (system/libcap is ver. 2.68).

Reply #10 –
Quote from: dreieck – on
but that neads something at the infrastructure level, and I totally can understand when people do not want to take that work.

I once made check-link-consistency tool which made into `universe` repo. It's user-side tool which runs over installed packages, not over some repos. But I honestly hoped maintainers will use it on their desktops, e.g. scripted after `pacman -Syuu` like I do. We all have some common set of software, long-suffering LibreOffice as example (BTW it stopped complaining about libcrypt.so.1 dependency only today), and doing so would allow them to catch at least SOME of problems before they're reported. But they didn't. For that reason I didn't offer my help in automating the task you described even when I had time and interest.

Is post-built scanning really needed? Don't the depends-arrays suffice?

Reply #11 –
Quote from: dimgel – on
Quote from: dreieck – on
but that neads something at the infrastructure level, and I totally can understand when people do not want to take that work.

I once made check-link-consistency tool which made into `universe` repo. It's user-side tool which runs over installed packages, not over some repos.

When building packages for repositories, is there really such a scanning like "check-link-consistency" does needed? 

Assume that the depends-entries are complete, wouldn't it suffice to just look at them, and whenever something package A depends on gets rebuilt/updated, package A also gets rebuilt/updated, and only when all packages in this dependency graph got rebuilt/updated any package (and all together) of this dependency graph are pushed to production repositories?

It's a bit simplified, because for arch=(any) packages usually a rebuilt is not needed, but to get the idea.

What am I missing?

Regards!

Re: lib32-libcap depends on non-existing libcap=2.67 (system/libcap is ver. 2.68).

Reply #12 –
> Assume that the depends-entries are complete

Well, they're actually not, see my tool's config by link from its README. But that can be found out only by checking link consistency of already compiled packages.

> whenever something package A depends on gets rebuilt/updated, package A also gets rebuilt/updated

Far too much rebuilds/updates. For example: when glibc updates (most probably -- in compatible way), should ALL packages get rebuilt? AFAIR (and I might not remember correctly, it's been a long time) Gentoo rebiilds dependent packages when dependency has major version upgrade, but NOT minor version upgrade nor rebuild. UPD: Of course, if some package's `depends` specifies exact dependency version, then even minor dependency upgrade should get dependent package upgraded too.

The simplest tool would just check `depends` & `optdepends` lines of ALL packages, matching versions from these lines with existing packages. Simple, stupid & fast.

Beyond that we fall again into checking link consistency. In case of build server, system cannot have all deps installed, so logic would change slightly: my first thought is to scan all package archives (UPD: not all, only direct deps of packages we've just built; check-link-consistency does not need to be recursive neither), collect .so paths, make map(so path --> package name), and when checking deps of packages we just built, find packages in that map by NEEDED .so libs, download & unpack them into /some-work-dir without installing, and search .so files in that /some-work-dir instead of system root.

Re: lib32-libcap depends on non-existing libcap=2.67 (system/libcap is ver. 2.68).

Reply #13 –
UPD2. Checking link consistency of package just built sounds pretty stupid. This should be turned upside down: we should check link consistency of all packages which depend on package we just built. That solves "far too much to rebuild" problem: we'll know exactly what we need to rebuild.