It takes work because the design of FHS is outdated and will eventually die off when we have working package managers that can deal with incoherency of their packages, and figure out a less heavy handed approach to redundancy.
Containerization isn't really the answer but it uses the same tools that the answer will have: chroot jails, Linux namespaces, and bind mounts + overlays. The problem with containers is that the layer model doesn't lead to anything actually being shared, but the basic feature set of the user lane gives the tools to a possible solution that doesn't suck. Nix is close, but suffers from design issues orthogonal to how it works. Maybe Nixos is the future once end users never need to read a flake.
isn't that part about containerization but using shared things at least partially handled by flatpak? I still hope we end up closer to what does or guix does, but at least it's a step in the right direction for various packages.
> sometimes you get lucky and the packaging instructions are easy to write (Debian rules, RPM specfiles, whatever Arch uses, etc)
Funny way to word this.
Arch’s PKGBUILD syntax is very very simple. If you now some programming (especially some shell scripting), you should be able to figure out all the basics. Here’s a non-trivial example:
Fedora’s specfiles are far from simple too… though you might be able to at least read one and get a vague idea of what’s going on.
I suspect both of these two are the way they are due to historical reasons… it’s a shame that they’re unlikely to change. There’s so much simpler way to write packages.
Ah, yes. Debhelper, and its many integrations. I routinely work with the various attachments dedicated to the management of sysuser accounts, systemd units, config files...
Yes, it's daunting. It also handles literally everything.
I can copy the commands from the PKGBUILD or APKBUILD and run them on a shell to replicate the same work. I can also pick up a random PKGBUILD and modify it to install some completely different package (this is how many people learn these packaging formats).
Looking at those three links that you provided for a Debian package, and I don't see a single clue as to how the package is built, nor how to adapt that to build something else.
I'm sure there's a manual somewhere, but that's the point: PKGBUILD and APKBUILD files are far easier to understand by just looking at them (assuming the reader knows some shell scripting). I actually just glanced through the whole documentation for the "control" file (btw: what does "control" even mean in this context?): https://www.debian.org/doc/debian-policy/ch-controlfields.ht.... Still no idea on how this builds todoman.
I'll also point out that I'm the maintained of todoman upstream -- so I _know_ how to build this software, but I don't see any clues as to how the debian package builds it.
I hope this makes it a bit clearer why one packaging definition is considered simple and the other hard.
If know what `%py_build`, `%py3_install`, etc are and do then is much simpler to write, read, and manage. There's a standardized way that all python packages can be made rather copy-pasting instructions around. Of course there's the hidden complexity those commands bring on what they're doing behind the scenes.
I have a collection of, and written quite a few myself, software which is nothing more than a single EXE. Most of them probably work on anything Win95 and newer. Their "installation" and "uninstallation" are trivial: Extract and run, delete once you've had enough.
In other words, packaging software is something that takes work only because of what might often be unnecessary complexity and a correspondingly bureaucratic process that's grown around it, and not because it necessarily needs to.
"Win32 is the stable Linux ABI" is more than just a meme.
So, don't need any configuration or preferences, then? It must suck to set up from scratch every time.
InstallShield was invented for a reason: the Win32 devs started dumping crap all over the system, all over the registry, and didn't bother cleaning up after themselves. A cottage industry of file and registry cleaners arose. Soon, software publishers began to learn how to properly package their software to be sustainable, and MS cooperated with Windows features to manage apps. Packaged apps.
What? If you haven't used the software before, what else other than defaults do you?
InstallShield was invented for a reason: the Win32 devs started dumping crap all over the system, all over the registry, and didn't bother cleaning up after themselves
That's a problem created by advocating for use of the registry, but not a necessity.
The single-file apps I have may create a config file alongside the binary, but that's it.
Which is already what it shouldn't do. The exe may live in a read-only directory that's accessible by all users. Putting config in %HOME%\AppData is not all that different from using the registry.
> What? If you haven't used the software before, what else other than defaults do you?
On Windows it (by the time I left it, around 2013) it apparently meant bundling various unrelated stuff (like installing Chrome, toolbars, McAfee antivirus trial). Half of installers had minigame "how to spot and stop crapware bundling".
Or at least asking blatantly obvious questions and lying that I read and accepted piles of legalese written by their lawyers.
Not sure has it got better.
Linux style packaging eliminated this for user, at least in my case.
> Linux style packaging eliminated this for user, at least in my case.
That's in part because of the target audience on Linux was historically of the kind that didn't give a damn about this. Compare how analogous CLI package managers (chocolatey, winget) work on Windows: the first thing after identifying what to install is to query whether you accept relevant licensing terms.
Yeah I don't know about that. In F/OSS there is traditionally no EULA to accept. There is a license to use/modify/share the software, and it may be a page or two long, and most licenses are found in just a few categories, such as MIT, BSD, Apache, GPL. Literally none of these licenses, in their original forms, place any restrictions or conditions on how an end-user can use the software; they're aimed at developers and contributors' use and distribution of the source and binaries.
Also, I don't know how non-Ubuntu package management organizes software, but in Ubuntu, you need to make a conscious decision to include the "nonfree" type of software.
Now presumably for a Linux package manager, any installation action should hopefully import any license terms to a known, readable place for the user to peruse, before launch, if necessary.
Perhaps many Linux users don't care, as you say, but I know a lot more who are exquisitely sensitive to licensing and EULAs and will scrutinize this stuff a lot more than a Windows user who just gobbles shareware from C|NET.
It's up to the application to maintain any preferences you set in it. The installer package generally takes care of path configurations, etc. It's amazing how easy it's been to make Win32 installable programs since about 1990.
Starting to using Linux the greatest part was no longer dealing with insane install processes. For example, end of game where every Java update was pushing some unrelated software and you needed to be careful to not end with it.
Also, "is it official site for this software or some copy of website or hijacked site" (and around time I left Windows SourceForge was busy with hijacking open source projects and adding malicious software to this downloads, maybe it got better since that time)
If all software would be unpackable and require no configuration by default and leave no waste files over system it would be OK.
That doesn't really align with the number of redistributable installers and "DLL not found" errors I've had to deal with during my Windows life. My wife's Win 10 system always boots to a "some DLL not found" fatal message, but after clicking OK everything seems to work as intended. I can't say I trust the way that system is set up.
I would venture to say you haven’t packaged or shipped any complex software or had to do so in a way that scales to hundreds or thousands of machines. This is along the line of “i could build uber with 50 engineers”.
Then again, taxis date back to at least Ancient Rome (IIRC they found a taximeter device using pebbles to count wheel rotations). And arguably, knowing humans, as soon as we figured out how to reliably use an animal to move a person, someone started offering moving people in exchange for money...
The Antikythera mechanism suggests quite a bit of previous art. Making a device for counting wheel rotations wouldn't be very difficult. You could do the billing on a wheel too! One set for each customer! But it would be easier to just do the billing by carving it into a clay tablet.
> I have a collection of, and written quite a few myself, software which is nothing more than a single EXE.
Trivial software for power users (who can download, run and find the exe again) has trivial packaging. This is the case on any system. Your app has no entry in the start menu, no file type binding, no services, no uninstallation entry in the control panel, no large dependencies, etc.
More correctly, the title could end "unless you only ever target Win32 on x86". Shipping software that's at all portable across operating systems and architectures, that's a different story.
Nah, even for that. I don't know what gp is on. I recently downloaded a project a friend made on rpgmaker. I had to manually download rpgmaker itself, a dll and a new font. It wasn't a complex project, he isn't even a developer, he mostly make illustrations and graphical assets. It was really, really basic stuff.
That said, I have almost 10 .exe that just work and that I take from computer to computer since 2015, like I have around 30 .sh/.py/.lisp that i do too. Being charitable, I think GP just have a lot of scripts/small tools that just work, and he was referring to that.
The majority of desktop users, perhaps. Most users are going to be customers of a system that likely runs “in the cloud" and that means, by far, Linux.
packaging is not much more work than building something from source. it's all the same process until the end step where you use the packaging tools to assemble the whole thing. it can get tedious when you end up having to package dependencies as well. but it's mainly grunt work, and none of the work is special to packaging. without packaging everyone would have to do the same work.
my favorite packaging tool was conary. it has automated packaging to such an extent that in most cases all that is needed is to tell it the command to run the build and install processes for that application. it figures out everything else by itself. which files are documentation, what are libraries. what are dependencies. one thing it did was to split a package into components. there is a :doc component, a :mysql component and others, which were especially useful for optional dependencies. if you didn't use mysql you could leave out the :mysql component and install the package without a mysql dependency.
where with deb or rpm i had to manually figure out what goes where if i wanted to split up a package, in conary that process was mostly automatic.
and, to address another comment here, conary worked just fine with the FHS. i do not think that the FHS was or is the problem. not being able to install multiple versions of a library is a limitation of the packaging tools. conary didn't have a problem with that, as long as packages were built without file conflicts conary did not get confused when you had multiple versions of the same package.
it's a pity that the distribution built on it did not survive.
that said, we do need containerization, but for a completely different reason: trust and security.
Containerization isn't really the answer but it uses the same tools that the answer will have: chroot jails, Linux namespaces, and bind mounts + overlays. The problem with containers is that the layer model doesn't lead to anything actually being shared, but the basic feature set of the user lane gives the tools to a possible solution that doesn't suck. Nix is close, but suffers from design issues orthogonal to how it works. Maybe Nixos is the future once end users never need to read a flake.