pkg_bundle - A proof of concept to make relocatable installs from binary packages

[kpedersen]

Hello all,

I am often annoyed by all the dependencies pulled in by some large packages that I occasionally use. I basically want to install i.e chromium and all of its dependencies in i.e /opt/chromium and that way I can have different versions and can simply delete the directory when no longer needed.

So, on OpenBSD I put together a proof of concept (actually I have used it for a while now, I just recently cleaned up the scripts a little) to generate relocatable package bundles for pretty much anything with minor tweaks (few binary patches involving pledge or gtk plugins + environment variables). If you are interested, please have a look through the project page at how this works and can be used:

GitHub - osen/pkg_bundle: Relocatable package bundles for OpenBSD

Relocatable package bundles for OpenBSD. Contribute to osen/pkg_bundle development by creating an account on GitHub.

github.com

In short, the following would create a folder containing Chrome and all dependencies that you can move wherever you like and finally run it:

$ pkg_bundle chromium
# cp -RP chromium /opt/chromium110
$ /opt/chromium/chromium

Don't think of it like flatpak, snaps or any of that weird Linux service stuff; think of it more as the traditional Mac OS approach where you could just simply drag and drop it to the Applications folder and that would be it; ready to go. Or at the very least Solaris style prefixes such as /opt/csw, /usr/sfw, /usr/X11R6, etc allowing different versions of packages in separate prefixes.

Now for the poll. How many people would find this useful on FreeBSD? I tend to use FreeBSD more for servers which has simpler packages compared to GUI stuff but I am actually very keen to see if the same process works on FreeBSD, including making a relocatable Xorg in i.e /opt/xorg.

Thanks (never run a poll before... exciting). If you specify "No", please do share your reasons. Or just everyone's general thoughts.

 

[yuripv79]

Don't think of it like flatpak, snaps or any of that weird Linux service stuff

But it really sounds like one of those?

Solaris style prefixes such as /opt/csw, /usr/sfw

This looks like bad example (that made me shiver) as those (ugly) things are completely different to what you are proposing (if I understand it correctly).

As for the poll, not sure if I really need this, but it would be interesting as part of pkg itself.

 

[kpedersen]

But it really sounds like one of those?

Flatpak and snaps provide runtime layers (and even services) to deal with the application images. All pkg_bundle will do is the raw software + deps in a directory and nothing more (i.e no additional sandboxing). So issues with two snaps/flatpak software trying to communicate (i.e web browser and paint program) is not an issue with what I propose. The best thing is that FreeBSD has compat libraries for libc, so in theory the bundles should be portable across major FreeBSD versions!

This looks like bad example (that made me shiver) as those (ugly) things are completely different to what you are proposing (if I understand it correctly).

Am I the only one on this planet who appreciated the Solaris approach!
I have updated that section to prioritize the macOS idea because you are right, that is a closer comparison.

As for the poll, not sure if I really need this, but it would be interesting as part of pkg itself.

It will be tightly integrated with pkg's repose as a way of fetching the packages and dependencies (check how I do this on OpenBSD, it is gross!). I think this will work quite smoothly. As for part of pkg itself, heh, perhaps one day if people like the idea and it proves to be scalable.

 

[patmaddox]

Where are you getting these different versions from?

I don't think that I would use this. I use jails when I want to isolate applications from the rest of my system. I use nullfs to share directories if I need to (including X11 socket), it works great.

I do think there's value in a more comprehensive and rigorous package versioning system, like what nix does. Right now, your best bet is to build ports at a particular checkout - but it's a PITA to pin specific versions. Even then, I would probably install a specific set of versioned packages to a jail rather than try to run them in the same place... but maybe. I can certainly see the value in switching browser versions, especially for trying to track down new bugs or regressions.

 

[free-and-bsd]

Am I the only one on this planet who appreciated the Solaris approach!

No, not the only one. I liked Solaris for what it is (i. e. was, when it was free to use). And it is those minor details/different approaches that make things what they are (as in different from one another). So, instead of being critical, my approach is to try to understand WHY ppl have done it this way. And in many cases I don't find overwhelming reasons in favor of one approach instead of another one.

 

[Beastie7]

This sounds like a good extension to poudriere than pkg. Extend poudriere to build the bundle straight from ports, or you could build said bundles into disk images (poudriere images (pmg) ?), that way you can do all sorts of storage stuff to it (ie. compression, password protection, etc); like on macOS. Hell, maybe even securely distribute them over the internet without a repo. pkg can be kept simple and lean. Just my two cents.

 

[kpedersen]

Where are you getting these different versions from?

A few approaches:

• Simply the release_0, release_1, quarterly, etc repos in the official FreeBSD package system. Most people just use quarterly or latest and leave it at that.
• Older releases of FreeBSD. With the i.e compat8x, packages from an old FreeBSD 8 could be bundled. Old versions of Gimp, Blender, OpenOffice or even Gnome 2 come to mind.
• Ports could specifically be built (bleeding edge, or old legacy)

I don't think that I would use this. I use jails when I want to isolate applications from the rest of my system. I use nullfs to share directories if I need to (including X11 socket), it works great.

That is fair. This is the approach I take for FreeBSD too. Often sharing files / programs between jails can be fiddly (i.e NFS setup) but certainly this is a solution.

but maybe. I can certainly see the value in switching browser versions, especially for trying to track down new bugs or regressions.

There tends to be regressions on browsers for things like Teams, Zoom streaming. If I could lock down a browser version into a "bundle"; even if it is fairly ancient, that would be useful I feel.

No, not the only one. I liked Solaris for what it is (i. e. was, when it was free to use). And it is those minor details/different approaches that make things what they are (as in different from one another). So, instead of being critical, my approach is to try to understand WHY ppl have done it this way. And in many cases I don't find overwhelming reasons in favor of one approach instead of another one.

On OpenBSD, I have an /opt/gnu folder where I dump pretty much anything beginning with 'g'. gcc, g++, gdb, gmake, gtar, gawk and errr... bash. I actually really like this and pretty much is what I liked from the Solaris /usr/sfw packages for the GNU licensed software. I find when this stuff is self contained, it gives it more of an identity; same with any "bundle"; I find myself enjoying the software more rather than just seeing it as something big and messy spamming my system.

Hell, maybe even securely distribute them over the internet without a repo. pkg can be kept simple and lean. Just my two cents.

I agree. Distributing the software as a big old tarball probably doesn't need pkg (or any package manager). Whilst "user-friendly" is rarely my goal, ironically this approach would be unique when it comes to UNIX/Linux and bring it more inline with how Windows/macOS users feel their computer should work (often because they don't know of alternatives). Didn't the PC-BSD project try something similar with the .pbi stuff?

 

[Beastie7]

I agree. Distributing the software as a big old tarball probably doesn't need pkg (or any package manager). Whilst "user-friendly" is rarely my goal, ironically this approach would be unique when it comes to UNIX/Linux and bring it more inline with how Windows/macOS users feel their computer should work (often because they don't know of alternatives). Didn't the PC-BSD project try something similar with the .pbi stuff?

Yeah, I believe the .pbi format was similar in concept. The helloSystem project is doing something along those lines too with their .app format. I think the poudriere image concept would work very well with window managers also, while being more native. I imagine someone could create a pmg from ports, then run something like poudriere open on the pmg, then boom, it opens.

 

[BaronBS]

I was think about this a few days ago but with a different approach, something like AppImage but with jails as motor.
And then today I found AppJail.

 

[kpedersen]

I was think about this a few days ago but with a different approach, something like AppImage but with jails as motor.
And then today I found AppJail.

In many ways, the way I use pkg_bundle is to generate a standalone package bundle to run in a Jail (or specifically, chroot). Just like on the native host, it is really just to simplify things so that you are dealing with a simple directory rather than more complex tooling.

 

[BaronBS]

In many ways, the way I use pkg_bundle is to generate a standalone package bundle to run in a Jail (or specifically, chroot). Just like on the native host, it is really just to simplify things so that you are dealing with a simple directory rather than more complex tooling.

But in this case it would only run where it was compiled? or not?

 

[kpedersen]

But in this case it would only run where it was compiled? or not?

No. The idea behind pkg_bundle is to be able to move it wherever you want (no hardcoded paths) without need for recompile. Almost like that "Portable Apps" stuff on Windows (or old Mac OS X .app directories you could place wherever).