Problem trying to install some packages files

Q&A
1

Hello Everyone , I am trying to install in Clear Linux some .rpm file but it Pops up that some other rpm and pkg are missing.
I have downloaded all the rpm missing from archlinux.pkgs.org.
While I can install rpm with yum command I couldn´ t figure it out of to install the .pkg.tar.xz files
for example:
1. iana-etc-20190504-1-any.pkg.tar.xz
2. filesystem-2019.05-2-x86_64.pkg.tar.xz
I can untar but not install.
Normally I use “#pacman -Sy xxx” but I haven´t it in Clear Linux.

I tried a lot of different solution but with no success.
Could you help to figure it out what I am missing and How to solve this Problem?

Thanks a lot and excuse me if it is a silly Question but I am newbie with clear Linux.

G

2

Hey @engineerGio81, Clear Linux doesn’t use RPMs to install software and repositories from other distros are unlikely to work. CL does however have the concept of bundles. Much of the software you’d expect is already packaged and available through bundles.

I recommend reading these 2 documents as a starting point:
https://clearlinux.org/documentation/clear-linux/concepts/swupd-about
https://clearlinux.org/documentation/clear-linux/concepts/bundles-about

If you find software you need isn’t available in Clear Linux, request it and we may be able to add it. If it’s not possible for some reason, we can discuss alternatives like compiling from source or using rpm2cpio for certain RPMs.

3

Packages from archlinux are generally entirely incompatible with clearlinux. The ones you listed are, for sure, not going to work.

However, the 2 packages you list are not functional items but dependencies. What are you actually trying to make work?

4

IMHO this reflects a general problem for users coming to Clear Linux from other distros like Arch and Gentoo where packages are complete, not split up into binaries / libraries, -dev or -devel with the header files, and -dbg or -debug for debug symbols. I came to Clear from Arch, but I’ve used Debian / Ubuntu, openSUSE and Fedora.

Having to hunt down build-time or run-time dependencies is an annoyance that far outweighs the disk space and download time savings achieved by splitting complete packages into three pieces (four in some cases in Debian / Ubuntu, for example, in the GIS stack). The bundles I make via the Clear Linux build tools will all have complete packages.

1 Like
6

Like many things, I think it’s a balance and tradeoff. Here’s my perspective:

The idea behind CL bundles and mixer is that all associated and dependency software is packaged together, with the dependencies resolved at build time before it gets to user, so most don’t have to think about it. If there is packaged software which doesn’t work out of the box due to missing dependencies, I’d consider that a bug.

The autospec tool and output of packages here clearlinux-pkgs · GitHub is essentially a blueprint of those dependencies. For developers, they can leverage those blueprints and the idea should be to improve the automatic detection of a packages dependencies so it’s less of a task.

For debugging, there is a feature in CL that automatically pulls debuginfo data on-the-fly with a FUSE filesystem so the process is streamlined, since the need for those symbols in point-in-time. This is being improved overtime but some is avilable here How to use the online FUSE debug system - #4 by ahkok and here https://github.com/clearlinux/how-to-clear/blob/master/07-3-debugging.md

1 Like
7

This breaks down for many R packages, which build from source on Linux by default. Try, for example, the CRAN package sodium (https://cran.r-project.org/web/packages/sodium/index.html). First of all, it won’t install because libsodium isn’t on the default system. With a sudo swupd search-file libsodium you can find the bundle that carries libsodium and install it. But the package still won’t build.

On Debian, it’s still a two-step process - try to install the R sodium package and it fails. However, the package developers were kind enough to tell you the name of the Debian package (and the Fedora / RHEL package) you need to install. It’s still a two-step process, but at the end you have the sodium CRAN package on your system.

On Arch it’s a two-step process, unless you’ve already installed the Arch sodium package because something else depends on it, in which case it just works. But since the R package developers didn’t do the kind thing for Arch users, you have to figure out which Arch package to install yourself.

My point is that you (and Red Hat and Debian) have forced the R package developer and the R package user to do extra work. Releasing packages as complete wholes, as the package developer designed them and like Gentoo and Arch and their derivatives do, lessens this work. It made sense when the .deb and .RPM package systems were created - disks were small and bandwidth was low. 20 years of Moore’s Law have changed the tradeoff between hardware costs and programmer time.

It’s more work for Clear maintainers too - your release engineering process builds all the binary RPMs anyhow, but you have to decide which RPMs go in the main bundle and which ones go in a “devpkg” bundle. And in the case of R packages and the GIS stack, you’re missing some capabilities. So you’ll get bugs that you have to triage. And people will run R and GIS in containers that just work.

1 Like