Software Application Standard
Software Application Standard
"Trying to be an RFC"
I was irritated at the prominence of (especially proprietary) software coming in a variety of formats. Some of the things that exist:
- .tgz binaries
- Archived binaries intended to be placed in /opt/pkg/...
- Installer .run files
- Installers that fetch the real files from the Internet
- General user-unfriendly console-run applications
ANOTHER package manager?
No, it's more of a format for your packages. It's more of a replacement for LSB/FHS than a replacement for DEB and RPM. It can be used with your
But we ALREADY HAVE a "filesystem as a package manager!"
This goes further than that by introducing things like architecture and operating system independence and making binary packages and archives truly universal and portable.
Wait, truly universal? Operating system independence?
The aim is to package several architectures of extremely small binaries that all use the same resource set. Any program requiring an uncommon library is either to be statically linked or for the library to be included. Although this might use a few more kB of space, it means that there won't ever be conflicting versions of libraries for packages, and will ensure that packages written for older operating systems will still work.
This means that one download will satisfy all operating systems, and will ensure usability.
Any user will be able to run a program downloaded in this format and will mean "installing" is always no more complex than copying or extracting a folder, as in RISC OS or Mac OS.
It is required all programs are created DRM-free for portability.
What do you mean, architecture independence?
Including small binaries for x86_64 Linux, x86 Linux, ARM Linux, OSX and Windows will not add a lot of overhead especially when shared bytecode-like libraries are used. This will make it easier to package and run programs, especially when the architecture is not known beforehand. When one or more architectures are not present a friendly fallback should occur.
Yeah, but what about macro-libraries? I'm thinking GTK, Qt, etc.
These will be included inside the program or used as a separate support program as an option. Every semver-enabled library can be linked to so the library can be updated separately. If a library updates and the package doesn't, this will no longer break the package.
Urgh, but what about library updates? Won't every single package need to change? I prefer not to download the same library dozens of times.
The option of not including (and just linking to) popular libraries is still available. This is to be properly ratified later. Probably using semver-enabled system libraries or existing package managers.
Won't this standard mess with my system files? I don't like my $PATH changing like port/brew/etc.
No, all packages are self-contained and do not have the need to fall into the system directories.
And updates? Won't the system fail to notice if they're not in a package manager?
This standard isn't a package manager so your existing package manager should still be able to update your system packages. However if you choose to use a setup or an operating system without automatic updates or use non-packaged programs, each program should still be able to download updates that won't conflict with the system from its own website automatically - and this is made extra easy as there is only one package to update, one set of resources and a couple of binaries to update if a source code change happens.
This standard is designed not to scare users who just want to get the job done. It will not require any console commands to operate (but will have the option for those who prefer it). The idea is for it not to require any extra special software to use - speeding up adoption and not having to wait for distros to implement it.
But I don't have this already. Nobody does. It won't be adopted because it isn't widely available. Just look what happened to [insert universal package manager here].
You could use a preload library to preview how existing packages on your system would use their tools, and you will be able to convert existing packages to see how they work.
There will also be pre-converted versions of popular programs, available in a kind of "free web store".
Wow! So when can I use it?
There will be a few demonstration packages in the near future when version 1 of the standard is decided upon.
What does it look like?
Package Name/ Binaries/ Triad/ <- perhaps OS Name/ <- from uname Architecture/ <- from $ARCH program.elf program.macho program.exe Libraries/ Triad/ <- perhaps OS Name/ <- from uname Architecture/ <- from $ARCH library.so library.dylib library.dll Resources/ <- Sprites, sounds, OS-independent materials Sources/ <- for building, optional