Puppy Linux Discussion Forum

I started using EasyOS and I love its principles, but I'm disappointed by how few packages there are in the default repositories. From what I understand, the idea is to partially rely on Appimages, but there are a lot of programs for which those don't exist.

I've thought of three approaches:

• Use the repositories from Fossapup.

• Use Guix as an additional package manager.

• Hijack the system with Bedrock.

The first seems the more feasible. I've given this a try by running a fossapup container and copying files and entries from /root/.packages inside the container to the same directory on the root filesystem and updating pupget. It did detect the new packages, but it didn't know where to download them from. I would need help with this method.

I feel iffy about the second and third methods, because it goes against the concept of Easy. Will the system still be able to run from RAM, or will it simply download too much bloat? And will I still be able to make use of containers? Especially Bedrock seems extreme: it will change the whole structure of the root filesystem, and download an entire distribution in order to make use of its package manager. I'm willing to simply give it a try, though.

I'm looking into such radical alternatives because I really need access to a lot of packages. Even under Puppy I wasn't content. Maybe the Fossapup repositories combined with Appimages, snap, flatpaks and the likes will suffice. Can anyone help me with getting this to work, as well as give general advice regarding which options are even worth trying? Thanks in advance.

Easy Bookworm seems to be on far back burner, but BarryK did mention experimenting with apt and Synaptic in Easy Bookworm. https://bkhome.org/news/202205/vanilla- ... gress.html Its mention is toward bottom of page.

I am getting interested in installing apt and maybe Synaptic in Easy Bookworm, but only if can get it to talk with the PPM.

I am also curious what Barry will do with apt, as I frequently use .debs. heres a more recent post at the blog https://bkhome.org/news/202208/plan-to- ... -dpkg.html

The .debs I install always work once I supply any needed deps. my best source of locating .debs and deps for .debs has been https://packages.debian.org/search?suit ... rds=foobar

I just left click on them to install.

I believe easy can also install binary packages from other distros. slackware? redhat? not sure

I have searched for documentation about the packages compatible with easy, but have yet to search the old forum. Perhaps Barry will weigh in on easyos current capabilities.

I will get back onto the Bookworm build, hopefully soon.

Right now, you can run Fossapup in a container, and have access to the big repo.

Hope to get back onto the apt <-> ppm convergence soon.

App images work . For instance try krita 5.1 alpha
https://download.kde.org/stable/krita/5 ... 4.appimage

or blender 3.2.2

https://www.blender.org/download/releas ... 64.tar.xz/
___________________________________________

deb2sfs a nice addition
https://bkhome.org/news/202209/easy-cre ... b2sfs.html
tx for making the sfs creation process easier

antithesis wrote: ↑Tue Aug 16, 2022 3:10 pm

I started using EasyOS and I love its principles, but I'm disappointed by how few packages there are in the default repositories. From what I understand, the idea is to partially rely on Appimages, but there are a lot of programs for which those don't exist.

I've thought of three approaches:

• Use the repositories from Fossapup.

• Use Guix as an additional package manager.

• Hijack the system with Bedrock.

The first seems the more feasible. I've given this a try by running a fossapup container and copying files and entries from /root/.packages inside the container to the same directory on the root filesystem and updating pupget. It did detect the new packages, but it didn't know where to download them from. I would need help with this method.

I feel iffy about the second and third methods, because it goes against the concept of Easy. Will the system still be able to run from RAM, or will it simply download too much bloat? And will I still be able to make use of containers? Especially Bedrock seems extreme: it will change the whole structure of the root filesystem, and download an entire distribution in order to make use of its package manager. I'm willing to simply give it a try, though.

I'm looking into such radical alternatives because I really need access to a lot of packages. Even under Puppy I wasn't content. Maybe the Fossapup repositories combined with Appimages, snap, flatpaks and the likes will suffice. Can anyone help me with getting this to work, as well as give general advice regarding which options are even worth trying? Thanks in advance.

Guix, see blog post:

https://bkhome.org/news/202409/guix-wor ... asyos.html

Barry, I just read your blog post about Guix.

Guix, or a similar system, sounds fantastic, and would be a HUGE game-changer for EasyOS, in my opinion. Ever since Easy switched from Buster to OpenEmbedded, I've been hoping for some universal way to install packages from a very large selection of them (one example being the big Debian repos) without having to use, as you said, paranoid sandboxes or containers running entire other operating systems. That's quite a bit of overhead and, for a LOT of software such as file managers (like my beloved XFE), it's quite impractical due to the filesystem isolation from the host system.

There really OUGHT to be a relatively simple way to do such a thing because after all, we're talking about Linux binaries which ought to be pretty universal. It should just be a matter of handling dependencies and some details.

Heck, I've successfully taken some .DEB files downloaded by Easy Buster's petget and manually moved them over to Easy Kirkstone and then kludged them into actually working on Kirkstone, so I know it's possible. It just doesn't work for all of them, and it's a pain in the butt, and the manual dependency-handling can suck. But it's possible, sometimes.

If Guix or a similar system can do this automatically with no such hassles (like a typical package manager does), it'd be awesome. THANK YOU for your experimental work on this and trying to get it working! I and many others would be THRILLED with an Easy version that can use big repos and install right from them directly into the main filesystem with no isolation or containerization! An additional package manager that can do this sounds ideal! (But of course also keeping flappi and appi for their unique advantages in other situations).

I'd never flirt with the idea of Mint again, honest!

Stogie wrote: ↑Sat Sep 21, 2024 3:54 am

Guix, or a similar system, sounds fantastic, and would be a HUGE game-changer for EasyOS, in my opinion. Ever since Easy switched from Buster to OpenEmbedded, I've been hoping for some universal way to install packages from a very large selection of them (one example being the big Debian repos) without having to use, as you said, paranoid sandboxes or containers running entire other operating systems. That's quite a bit of overhead and, for a LOT of software such as file managers (like my beloved XFE), it's quite impractical due to the filesystem isolation from the host system.

Unfortunately, Guix is not so ideal. It does virtually install an entire OS, like flatpaks.

I am abandoning Guix, see my blog post:

https://bkhome.org/news/202409/decided- ... asyos.html

I'm going to add more apps to Flapi.

Regarding native apps in PKGget; I need suggestions.

I don't know about KDE apps. I suppose could have a go at compiling them.

BarryK wrote: ↑Sat Sep 21, 2024 6:10 am

Unfortunately, Guix is not so ideal. It does virtually install an entire OS, like flatpaks.

I am abandoning Guix, see my blog post:

https://bkhome.org/news/202409/decided- ... asyos.html

I'm going to add more apps to Flapi.

Regarding native apps in PKGget; I need suggestions.

I don't know about KDE apps. I suppose could have a go at compiling them.

Barry, give this a watch. Mental Outlaw on YouTube demonstrates the Nix package manager in 13 minutes, good video, this might be the answer. It lets you install almost anything (the Arch Linux AUR repo alone has over 87,000 packages, for example) on any Linux distro pretty easily, it looks like. He installed the Nix package manager with a single "curl" command, then just ran it and it worked, and as a test he used it to install LibreWolf in seconds, and it worked fine:

Apparently you use the Nix package manager commandline, or their website, to search for a specific package you want, then you install just that one. Notably he does NOT show or mention a drawn-out process of gazillions of package definitions being downloaded/updated. So that problem may not exist. It may not download or store a giant list of available packages locally at all; it may only go get one (and its required dependencies) when you ask for it specifically. That'd be ideal, because it'd be lean and mean and fast with no unnecessary time or storage used for maintaining giant locally-stored lists of all available packages, that giant list may only exist on the remote servers for you to search in (which is the way it should be!)

Not sure how much bloat it has/installs, but it looked simple and fast and he doesn't mention any giant bloat (and knowing him, he would if there were any), so that problem may not exist either!

He specifically says it solves the problem with different Linux distros having very different repo contents, which turns off many Windows and Mac refugees from using Linux, and he says this fixes that by letting any distro install almost anything, and that's exactly what we're looking for here.

He also says it takes snapshots before each package is installed, and you can rollback to them easily if the package doesn't work or misbehaves.

Heck, from his demonstration, you may not even have to include it in Easy (but you should if it's suitable). It looks like any of us can just "curl" to install it, then just install whatever packages we want right away.

I'm no expert, have a look for yourself though! It sure sounds promising at least! It might be ideal for Easy.

Annnnd, after making my post above, only now did I just notice Caramel's big detailed thread about the Nix package manager:

https://forum.puppylinux.com/viewtopic.php?t=8904

From that thread, it looks extremely complicated. That Mental Outlaw video (above) makes it look quick and easy. So I don't know, maybe it's not a good fit for Easy after all.

This is the one and only way in which I miss Windows. If I wanted something, I installed it, the end. Quick, easy, worked every time and I could install ANYTHING that's made for Windows, because there was only one kind of Windows, not 5,429 different "distros" of Windows with hundreds of different "repos" each of which only had SOME software I wanted.

Also it didn't require a PhD degree to figure out how to install the software (package manager) that then installs more software, which also may or may not have worked right.

If only Linux could fix this issue, they'd get A LOT MORE desktop market share I think.

antithesis wrote: ↑Tue Aug 16, 2022 3:10 pm

I started using EasyOS and I love its principles, but I'm disappointed by how few packages there are in the default repositories. From what I understand, the idea is to partially rely on Appimages, but there are a lot of programs for which those don't exist.

I've thought of three approaches:

• Use the repositories from Fossapup.

• Use Guix as an additional package manager.

• Hijack the system with Bedrock.

I have just started to investigate Bedrock:

https://bkhome.org/news/202409/easyos-a ... linux.html

@antithesis thanks for bringing Bedrock to my attention. I know you posted that in 2022, but I only just today checked it out.

@BarryK :-

BarryK wrote: ↑Sat Sep 21, 2024 6:10 am

I don't know about KDE apps. I suppose could have a go at compiling them.

You might find you'll be biting off more than you can chew, Barry. Anything to do with KDE makes, shall we say, assumptions about your system & software.

For a start, you'll need to have the FULL install of whatever Qt build happens to be the current stable release......ATM, this is now somewhere around Qt6.5/6.6. Absolutely everything in the KDE eco-system is compiled & built against this, and newer builds of Qt are just getting chunkier & chunkier, release on release.

(Modern hardware is getting more & more capable, very rapidly. Top-end consumer hardware frequently comes with 32 GB of RAM, 64 GB is often offered as an option, and even 128 GB RAM is getting mentioned more and more. Consequently, you now have an entire generation of young, wannabe coders who think nothing of including a couple of GB or more of dependencies just to get even a small package working. "Oh, everybody's got tons of resources now, It won't matter. They won't notice it..."

Nobody takes any pride in trying to keep code small & efficient any more. Sad.....but true.)

=========================

On top of the Qt requirements, almost every KDE app - with very few exceptions - is also built with the automatic assumption that the full Plasma desktop environment is present & correct, along with the Dolphin file-manager........because in a normal KDE install, these would be.

individual KDE apps aren't that different to most other apps, size-wise. It's the required dependencies that bloat standalone KDE packages up beyond belief.

I've created a few standalone KDE apps as portables, invariably based round AppImages. One very good example of this is the Digikam image organiser/editor/archiver. This has been available in AppImage format for a long time.

The 5-series AppImage that I re-packed is somewhere around the 475 MB mark. Compared to the current 7/8-series builds, this is svelte; the new ones now run out at nearer to a gigabyte.....yet they work, flawlessly, because all of the above requirements have been fully taken into account.

This doesn't suit many folks, because packaging things this way goes against traditional Linux practice, where your package manager only adds stuff as & when it's required. With AppImages/Flatpaks/Snaps, there is often massive over-duplication of the same basic dependencies, since these types of packages look to include absolutely everything needed for them to run.

What you lose in the way of available system resources, you gain in convenience. So the thinking goes.....

(*shrug...*)

Mike.

mikewalsh wrote: ↑Sun Sep 22, 2024 10:09 pm

@BarryK :-

BarryK wrote: ↑Sat Sep 21, 2024 6:10 am

I don't know about KDE apps. I suppose could have a go at compiling them.

You might find you'll be biting off more than you can chew, Barry. Anything to do with KDE makes, shall we say, assumptions about your system & software.

Ha ha, yes.
KDE does officially support cross-compiling with OpenEmbedded/Yocto; however it is now using Qt6.

My OpenEmbedded build is still on Qt5, using the Scarthgap release of OE. However, KDEs Qt5 OE support is only for older versions of OE. As I found when tried to compile KDEs Qt5-based OE -- some compile fails.
Too much trouble, and I'm not ready to move to Qt6, some apps that I compile in OE need Qt5.

Doubt anyone wants to know this, but here is KDE's official Yocto support:

https://github.com/KDE/yocto-meta-kde