Appimagekit: Poll: Would you rather have a package manager or download applications from a website?

[simoniz0r]

Please vote in the strawpoll below, thanks!

https://www.strawpoll.me/15489837

[probonopd]

For the 99% of people who will vote with "package manager", _go use a package manager_. AppImage is not designed for you.

AppImage is designed to make using applications on Linux desktops as easy as it has been for Mac users since 1984, namely: drag-and-drop.

[simoniz0r]

There's no reason why AppImage cannot provide both. AppImage can work without a package manager and with one just fine.

[probonopd]

I don't know what there is to downvote. If I like white chocolate, I eat white chocolate instead of trying to convince people who like dark chocolate that they should rather eat and produce white chocolate.

[simoniz0r]

There's no reason that you can't produce things you don't like. It's called catering to the market that you're trying to push your product to.

[probonopd]

People can "manage" AppImages using a package manager, but that dilutes its user experience, which is designed for being "managed" in the file manager. "1 app = 1 file", "file manager". Notice something? ;-)

[probonopd]

There's no reason that you can't produce things you don't like. It's called catering to the market that you're trying to push your product to.

If you are a business. But this is a hobby for me.

[simoniz0r]

No, I don't. You need to stop being so silly and realize that users would really like a package manager for AppImages and you're really preventing package managers from working well with AppImages by being so stubborn.

[simoniz0r]

Quote from another Linux user:

so the point of appimage is to make installing linux programs as inconvenient as it's been on Mac since 1984?

I really don't think you realize how convenient package managers make managing applications.

[probonopd]

you're really preventing package managers from working well with AppImages

No. Putting an AppImage into a deb/rpm package is as hard or as easy as putting any other ELF file into a package. I just happen to think that it is counterproductive.

[simoniz0r]

Who the heck said that we're putting AppImages into debs and rpms?

[probonopd]

I really don't think you realize how convenient package managers make managing applications.

Maybe. Personally I find them awesome tools for the people who put together OSes, but not something an end user should have to interact with. But my point is: I totally respect users who think that package managers like rpm and apt are awesome, but then _please continue using them_ instead of trying to equalize AppImage.

[probonopd]

Who the heck said that we're putting AppImages into debs and rpms?

If you like package managers, then why not use one of the best package managers there out there to manage your AppImages. An AppImage is just an ELF executable, like bash is. It could be managed by the same package management tools. But again, I think it would lose a lot of its value in doing so.

[simoniz0r]

You don't realize how convenient AppImages can be for users who don't get the latest updates in their package manager's repos. Users can install AppImages without having them touch anything on the system and without risking the rest of the system breaking because of incompatible software. Providing this in a package manager changes nothing other than making it more convenient for the end user.

[E5ten]

Because that would go against the whole point? the point is to make a package manager that you can just ship to any distro that specifically grabs appimages, it's not to make appimages work with various package managers for different distros.

[TheAssassin]

JFYI both of you, AppImage "package" managers available _today_:

https://itsfoss.com/ocs-store/
https://github.com/nomad-desktop/nx-software-center
https://github.com/simoniz0r/appimagedl

[probonopd]

These I would not call "package managers" but "app centers" and these are imho different beasts. People are welcome to make them. As long I can also get e.g., the Krita AppImage directly from the original location at krita.org ;-)

[simoniz0r]

I don't at all consider appimagedl to be a software center. It is very much a package manager.

And in creating it, I've had to work around many of the things you do here which are not at all friendly to package managers that would wish to work with AppImages due to your macOS based philosophies.

[E5ten]

If you consider them app centers then you must not have clicked the links because appimagedl is a command line tool...

[probonopd]

OK, then where is the problem? Already three choices out there, like always in the Linux world.

[simoniz0r]

Like I said, it's pretty hard to work with AppImages in a package manager the way that things currently work. With appimagedl, I'm only able to provide links to github packages reliably because you refuse to keep track of versions and have direct links to the latest versions of AppImages.

[TheAssassin]

The main reason this whole issue is ridiculous when reading without being involved is the term "package manager" isn't really described.

For @probonopd this project is a hobby that started >10 years ago, and evolved to some medium size open-source project. It provides a special user experience that _intentionally_ breaks with existing solutions. And a hell lot of people like that new experience.

Why is it always necessary to discuss the same thing 100 times? @simoniz0r you _need_ to accept that _you_ are not the one who can force any developer to do something _you_ want them to do, just because it's you. In the real world, you need a _reason_ to make someone do what you want them to do. Either you pay them money, making the other one your employee. Or you sell them the idea with arguments that convince the other person. None of these cases applies to most of your suggestions. In the latter case, convincing somebody of some concept that breaks with their own ideas is extremely hard. And if it doesn't work, well, you need to accept that...

[simoniz0r]

Not at all trying to force anything on you; just trying to open your eyes to what the community wants from AppImages.

It'd be really nice if AppImage could do just a few things to make managing them with a package manager much nicer to do, but the stubbornness from the AppImage camp is pretty hard to deal with.

[probonopd]

Well said @TheAssassin.
It's not that we are _preventing_ what you want to do @simoniz0r - It's just that _you_ need to do the work, rather than implying that _we_ should do it _for you_.

[simoniz0r]

You are, though. In not providing any sort of reliable update info, you are making it a complete pain in the butt to manage AppImages. The solutions you do offer do not work reliably enough to be used full time. Just the other day I had appimageupdatetool completely stop working as expected, and I had to remove it completely from an app I'm working on.

[probonopd]

I am sure you opened an issue at https://github.com/AppImage/AppImageUpdate. ;-)

[simoniz0r]

Nope, I sure didn't because it's actually easier for me to just reinvent the wheel here than continue to use the tools you provide, unfortunately.

[TheAssassin]

just trying to open your eyes to what the community wants from AppImages.

I really understand your efforts are mainly because you want to improve AppImages. But many of your suggestions don't represent the majority of our users.

Really, we are not trying to prevent you from using AppImages, and we're open to suggestions. But there's a core set of principles that won't ever change. These principles are the foundation of the AppImage idea.

I am really willing to help you improve your own experience, and I hope you can make use of the provided tools to implement _your_ imagination of the Linux desktop. There is a reason we provide developers with libappimage, libappimageupdate, etc., we do encourage everybody to make use of AppImages and the official projects to implement new ideas. And eventually, some of them are even taken over by us and are becoming official solutions.

[probonopd]

AppImageHub, for exactly this reason, is made in a way that anyone can fork and improve it in any way they like. Including checking for new versions every 2 seconds. ;-)

[simoniz0r]

Honestly, I'm not trying to be a prick or anything here, but the code base there is not at all easy to work with and does not lend itself to being forked.

[TheAssassin]

In not providing any sort of reliable update info, you are making it a complete pain in the butt to manage AppImages.

I don't see how any update information wasn't reliable. In fact, we often have discussions in zsync2 and AppImageUpdate about new methods being less reliable, and whether we would want to accept this kind of reduced stability. The update information providers are themselves tested and well known to work. If you think there is a problem, please report it, and you can discuss them with people who are into these topics and can provide you with upstream information.

The solutions you do offer do not work reliably enough to be used full time. Just the other day I had appimageupdatetool completely stop working as expected, and I had to remove it completely from an app I'm working on.

Not reporting issues intentionally is really against many of your points. Of course, being software projects, they're prone to bugs, and these need to be fixed. AppImageUpdate uses a load of legacy code that is being improved over time, but there hasn't been time to replace these yet.

If you had described your issue, we'd probably have found a solution. However, reading a sentence like this is really a downer. Think: Why should we continue to listen to you, if you don't share such information with us (but possibly with third parties)?

Of course, you're not bound to AppImageUpdate at all. But you shouldn't write that you don't use it because of an undiscovered bug that you didn't even report, although you regularly visit our issue trackers. I hope you will report issues you find in the future to the upstream projects. It's the foundation of the free software development.

By the way, there's a few software projects who use libappimageupdate in production already, and we haven't heard any complaints about instability. Most of the restrictions it currently has are documented.

[TheAssassin]

but the code base there is not at all easy to work with and does not lend itself to being forked.

You think it is fun for me or or anyone else to work with the current code base? Think again. (@probonopd is aware of this, of course :))

By complaining about it, it won't get better, though. I've been fixing a load of issues in it recently. We're working on improving the code style and fixing bugs. We're even discussing to make the non-runtime code C++, to reduce the amount of manual memory management and cleanup patterns.

[simoniz0r]

I don't share info with you because my experiences with this project have been like butting my head up against a wall. If you really wanna know, appimageupdatetool just kinda fails to spit out any actual update info when the -j argument is used. It used to output the information for an AppImage, but now it just spits out one line of text for GitHub AppImages and errors out for the rest.

appimageupdatetool -j ./bin/appimagetool
Fetching release information for tag "continuous" from GitHub API.

appimageupdatetool -j ./bin/libreofficedev
zsync2: Bad status code 404 while trying to download .zsync file!
zsync2: Reading and/or parsing .zsync file failed!
Error checking for changes!

When I run into things like this in addition to the lack of github rate limit awareness and this projects extreme hatred for config files for some reason, it becomes very hard for me to want to continue to use the tools that you provide.

[TheAssassin]

@simoniz0r -j is communicating its state via the exit code, and writes only status information for debugging. If you want a description of an AppImage, please use -d. The description contains the update information.

[simoniz0r]

When did this change? lol... it used to provide the update info through -j...

These types of things are exactly what I mean; changes like this make your tools unreliable for me to use.

[TheAssassin]

I am sure that -j has never returned the update information. It's especially meant for update checks. Please see the help text.

Would you like to undermine your claim with a commit diff? Wild claims like these make discussions with you demanding.