search

probonopd / go-appimage

Go implementation of AppImage tools
MIT License
676 stars 69 forks source link

Fixes #251 #252

Closed CalebQ42 closed 1 year ago

CalebQ42 commented 1 year ago

A simple fix for #251 by replacing log.Fatal in a few places with log.Println.

probonopd commented 1 year ago

This would allow the program to continue (in a broken state) but doesn't really fix the issue that causes the malfunction.

probonopd commented 1 year ago

@CalebQ42 would you agree that it is better to not run at all rather than to run in an unsupportable half-working "random" state?

CalebQ42 commented 1 year ago

For me it comes down to 2 main reasons that it would be fine the ignore the error in this instance:

  1. The problem (at least in #251) is not originating in appimaged, but instead with the external service (zeroconf) which we have minimal control over.
  2. I honestly haven't done that much research and investigation on what exactly the zeroconf is needed for, but from what I can tell the error does not largely impact the core functionality of appimaged.

Ultimately this is similar to your decision to not add configuration to appimaged where you end up with multiple different setups that can each have their own quirks and problems. Though I might disagree with it, it is a 100% valid decision that I will happily follow since it is your project.

Sorry if this isn't very elegantly put, I'm fairly sleep deprived ATM, lol.

probonopd commented 1 year ago

You are right in that we are currently not yet making use of Zeroconf. It is something I wanted to do but never came around to doing so far. The idea was that appimaged instances on the local network would find each other, and AppImages could be exchanged/updated over the network "automagically".

Instead of leaving this in a half-working state, I think the cleaner option would be to comment out Zeroconf entirely for now, until we really start making use of it.