Should pkg be able to install RPMs?

[UnitedMarsupials]

Many of our linux-foo ports do little else but unpack and install the prebuilt binary RPMs under /compat/linux. It'd be nice, if such simple installations could be done directly -- without each package (and its dependencies!) requiring its own port...

One way towards this goal is to add a libpkg-registration plugin to the archivers/rpm4 -- and otherwise make it usable as not just archiver, but also a package-manager (however limited) on BSD.

The other, perhaps, more straightforward, way would be to add the ability to install RPMs -- under /compat/linux -- directly to pkg itself. The libarchive is already able to extract files from the RPMs..

We'd just need to figure out details like the virtual category for such packages (rpm, linux-c7?), whether or not to execute an RPM's embedded scripts, and from where to download the requested RPMs by default.

The reward for this effort would be the eventual ability to install -- and even depend on -- most Linux RPMs without creating and maintaining a port for each. For example something like:

-RUN_DEPENDS=	linux-c7-curl>0:ftp/linux-c7-curl
+RUN_DEPENDS=	rpm/curl

Theoretically this might be done for other packaging formats -- such as .deb -- too. Practically, only the CentOS-7 RPMs dominate (as CentOS-6 used to and as CentOS-8 soon will)...

[bapt]

the repository handling is pluggeable (aka we can create alternative repository formats) so yes this has been in mind for pkg for a while, and I would great any patch in that direction

[arrowd]

While the idea sounds great, it'd require a lot of work on the Ports infrastructure side to get it working. We'd still need some linuxulator ports to stay as they do too much fiddling with the installed files. We'd also need a way to depend on RPM packages from a port.

[bapt]

the point would be to directly use debian and/or any RPMs repo without using the ports tree.

[arrowd]

I don't think it'd work completely without ports. Imagine that some RPM being installed needs untrivial "patching" of some sort. I see no way to tell pkg to perform this patching during installation of this specific package.

Using ports allows us to mix and match vanilla RPMs and linuxulator ports that aren't trivial enough to be handled by pkg itself.

[bapt]

100% of the linux packages are installed in archlinux or debian chroots that I have, without a single bit of linux things from the ports tree, so I can tell you it works ;)

[UnitedMarsupials]

repository handling is pluggeable

What about file-format handling? Where would I go about adding handling of RPM-header instead of the +MANIFEST?

yes this has been in mind for pkg for a while, and I would greet any patch in that direction

Wow... What a pleasant meeting of the minds :)

it'd require a lot of work on the Ports infrastructure side to get it working

Of course... But that work cannot even begin until pkg grows the necessary functionality, so let's get started.

Imagine that some RPM being installed needs untrivial "patching" of some sort.
I see no way to tell pkg to perform this patching during installation of this specific package.

I expect most things to become installable without a port... Some others, that need BSD-specific "patching", may switch to depending on the RPM, with "patching" done afterwards. And, lastly, some things might still be best installed via a dedicated port -- the way all of them are now...

[bapt]

someone needs to design the whole things, the only part that has been made pluggable for now is the repository.
The support for the specific file format needs to be thought, designed and implemented