If you need help. I am willing to go down the rabbit hole of researching and packaging up a flatpak. I would hate to see such an awesome project kneecap itself right out of the gate. By going through .deb packaging and maintaining hell while severly limiting your success potential.

Reply to this note

Please Login to reply.

Discussion

Everyone and their mother uses apt, tho.

once the package creation scripts are made it's not really that bad

and debian is by far the most common base for linux installations, the need for snap and flatpak and appimages has failed to materialise

We also have Nostr-native packing solutions. I'd probably prioritize those, since that's where the beta-testers will be.

You all must be living in a bit of Linux bubble. I try to stay updated on the entire family tree and distrohop to stay apprised on the latest developments.

Flatpaks and snaps are highly used on a daily basis now by the majority of distros when their repositories are out of date, or do not have what they need. Many large companies would now rather package up once and ship everywhere. Than to deal with one Linux distros package management process over the other and miss out on valuable market share opportunities.

Just use logic and reasoning on this one.

Would you rather use flatpaks, appimages, or snaps and be able to have an unlimited audience.

Versus using deb packages, signing up for inevitable dependency hell headaches (guaranteed), and only ever having a medium size audience.

If anything, after deb packaging, I believe we’ll do rpm for the Red Hat and Fedora distros.

Ah. I use that at work, for installations on the testserver.

Ah very well. Your server must be running a Red Hat Linux.

I was wondering why they were using it. That explains it, thanks.

it could be opensuse also, that uses rpm too

iirc, opensuse is a german distro, or at least it's european, debian is american

It is german !

as i understand it, quite widely used by german companies

basically nobody else in the world uses it... it also has a slightly different tool called "zypper" iirc, that does something like apt for deb packages as zypper is for rpm, similarly there is dpkg and then there is rpm

i might be misremembering, i ran opensuse for a little while

i approve of this policy... i avoid using snaps or flatpaks as much as possible because they tend to be bugging, still, with their isolation and being able to access my home directory

Tried to install a flatpak on Saturday, but it was like 15 steps and in the end it didn't work, so I installed something else with apt.

https://distrowatch.com/dwres-mobile.php?resource=family-tree

You are choosing one branch of the Linux family tree over the other. Alienating hundreds of other Linux distros by giving preferential treatment of Debian based ones over the others.

For example when you enter the enterprise landscape you may find that there are more RHEL based distros. Than Debian based ones that are being used.

When you decide to go down the Debian path you have to consider the dependency hell you are signing up for too. When there are major version releases of Debian, or Ubuntu based distros your dependencies will always be out of sync with each other. Debian will always be behind and ubuntu will be ahead. Leaving your users up shits creek to paddle themselves out of the mess.

In the Linux world there is a shift towards a more universal package management approach. With flatpaks, appimages, and snaps being the preferred choice for Linux package management and distribution. This is, because by bundling the dependencies with the application and maintaining them in this method. You do not have to worry about the dependency hell.

With flatpaks you make one package that will work with every Linux distribution. Easily updated and maintained gracefully. You can use debs if you want, but when you ultimately experience the headaches later. Remember there are better more up to date solutions that can better the Linux community as a whole. Not just one biased branch of the family tree that is slowly becoming obsolete.