I don’t like those package formats because… most of the time they don’t give us the CLI tools or a version of the App that we can just run from the CLI out of the box without having to fight with the app a bit.
They are for Linux, they should add command line tools out of the box, but they don’t. Snap also hides /tmp folder which is a pain… their things discard the best part of using Linux.
Yeah, but the treadoff is being pushed to the wrong people sometimes.
If the use chooses it, it is fine. But sometimes (using Freecad as example here), this is being pushed by developers that are being lazy to make packages for the package manager of the OS.
Huh? Nobody pushes anything on anyone. You are free to not use freecad or compile it yourself or use another OS or package it however you wish or wait until someone else does or whatever.
Invalid expectations of devs having to package their software for your OS of choice != something being pushed.
Actually you’re wrong about flatpak. You can run the executables within the flatpak from the CLI. I know because I recently built a flatpak for gcc for the ia16 architecture. But the invocation format is quite verbose, and if one really wants to do this one would use aliases, shell scripts or launchers to access the command.
$ flatpak run --command=ia16-elf-gcc io.github.gcc_ia16.Gcc_ia16 -v -o hello.com hello.c
Using built-in specs.
rt_specs_files_spec_function: accepting specs file r-msdos.spec
Reading specs from /app/lib/gcc/ia16-elf/6.3.0/../../../../ia16-elf/lib/rt-specs/r-msdos.spec
...
Fkatpak allows one command to be the default, which is why flatpak is better suited for applications like gimp where there is a single app to run, and you can hide that long invocation inside a launcher.
But this is not going to be a exposition of how to use flatpak. Nobody is forcing you to use any flatpak, snap or appimage. Some kind packager provided these cross-distro packages to help users who would not have access to a native package. That packager is providing an alternative to compiling your own, which is beyond most people. Flatpak has drawbacks which you’ll discover which is due to how the sandboxing works. That’s why a native package if available is preferred.
It’s so easy to toss around the pronoun “they” when complaining without pausing to think who “they” refers to. Packagers who build for distros, or flatpak makers, are not necessarily developers who work on the code. They are often volunteers. It’s not a conspiracy to push flatpaks over native packages. Rather the flatpak builder is trying to broaden the audience for KiCad. Just like the other apps that are packaged as flatpaks. So stop blaming devs for something a volunteer did to provide more options.
I said we can run it, but we cannot run it out of the box like any other program.
This dump of text that you showed is not a command but is a possibility of a command, no one is going to use it “without having to create an alias”. The “aliases” could come as default.
but see, if I have to complain with the developer of the tool they are not “ready” for all the tools. Unless you are saying I can complain to the developer of the package manager.
Well, this is why I don’t use this kind of format because they don’t give me the full Linux experience. I use them just when I don’t have a choice.
Ask the person who built the flatpak if they can supply a shell script to shorten access to the commands in the package. It’s the same story for all flatpaks. That’s why flatpak is, like I said, better suited for apps like gimp which have only one entry point.
I realize that some of this may be language related, but ‘if I have to work with the developer’ is a better way to think of and state this. This is open source. We all have the goal of improving the user experience.