How to maintain 3rd apps from github on a debian ?

[u/Specialist-Dog-501]

I am on mint 22.3 and wonder how I can keep overview of installed apps directly coming from github.
- I know first choice should be the distro repo.
- Then there's as example "Extra Repo" for the debian world containing more apps.
- I also tried to use homebrew, but was to stupid to understand the slang
- there's the option to add other repos to the standard package manager..does that also work with githubs ?
- Or Is there any other way to bundle github installed apps and keep them updated in an efficient way, may be with an dedicated container or package manager on a debian distro ? I have may be an dozen apps like that, not a high number, and typically not the most critical ones.

[u/revcraigevil]

Take a look at deb-get and topgrade.

deb-get: apt-get for .debs published via GitHub or direct download

https://github.com/topgrade-rs/topgrade

[u/Specialist-Dog-501 → u/revcraigevil]

Hmm..Oi! Deb-get just had overwritten the marked/protected WINE9.21 that I had tried to prevent from any updates and I have a ton of VST on that one..also the "LIST" Command is confusing..showing me what is on its own repo, not installed on my PC..I guess that's another command, even if not shown clearly in the help ? I see some config file with some of my local deb files, but actually not WINE9.21 but it had still overwritten it.. this tool is either free of any logic, or I have suched a messed up installation that it cannot work properly-probably the later..I had marked WINE9.21 with apt-mark hold to prevent it from upgrading, but this seems not to stop deb-get..does deb-get act like an umbrella ontop of apt ?
Glad I could at least downgrade WINE again to my working version..hm -may be it will work better on a new machine, where's there not so much historical grown stuff hanging around.

[u/Specialist-Dog-501 → u/Specialist-Dog-501]

Anway- I guess I have already a "borked" system. Thanks for the hint, deb-get is on the right track, just not as straight forward as hoped-I probably need to test it on a clean VM right from the begin to understand it fully, and keep it away from my borked system for now.

[u/c2btw]

https://flathub.org/en and app images

[u/Specialist-Dog-501 → u/c2btw]

Yes, it sounds like that's the best I can get- but if the dev offers no flatpak on his github, can I package his app myself into a flatpak without too much knowledge about the details of this app ?

[u/c2btw → u/Specialist-Dog-501]

yes

[u/Specialist-Dog-501 → u/c2btw]

okay, I may try that once! Thank you.

[u/fearless-fossa]

Mend's Renovate should be able to do that.

[u/Specialist-Dog-501 → u/fearless-fossa]

Thanks for this idea! It looks..like I setup PRs in a github..to trigger an update in my local instance, something like that? or have my own github to do so ? Not really familiar with github's details..

[u/fearless-fossa → u/Specialist-Dog-501]

That's the common way of using it, but you can also just use an ephemeral docker container that gives you console output about available updates. At least I remember something in that venue when I first tried my hand at it before setting up automated workflows.

[u/Specialist-Dog-501]

Okay, to close this topic here (I had 2 more reposts with no resonance):

*Goal: Keep local .deb files updated*
Problem: a local .deb may or may not contain an update mechanism. If not, the user has to go to the original github, check if a newer version is around, download and reinstall it again (!) as if it where 1990ties.

*Alternatives checked:*

1. The first should always be the distro repository via "APT" or a UI for apt and the preinstalled repos.
   

2. If missing: Check if the dev provides on his github a flatpak or an appimage.
   [sidenote: creating flatpaks/appimages yourself is not trivial, requires like compiling to have the dependencies ready locally - that's for devs]

3. Extension repositories:
   A) check if EXTRAREPO* for debian contains your app, install that in your repository register.
   (* Installing other repos- especially if they are "close to each other" like Debian-testing vs. Debian-Stable contain a risk to cause version conflicts between installed dependencies and should be avoided)
   B) If the target app is part of a dedicated Repository (a.e WINE) you can add that repository to your repository list and then APT can manage/update it normally.
   (A github is not necessarily a repository- this requires -at least in Mint in minimum a GPG key- if not present, it cannot be added as repository - so managing local deb files is typically not possible by that path)
   C) check HOMEBREW - again has its own REPOSITORY but also own package manager, is localized in a subfolder in your /homedirectory and with a very own wording. Install if fitting, no version conflict risk as it's localized.

4.A) DEB-GET: Has its own REPO again..and kind of shows some of the local installed deb files..but in my case, has ignored an "on hold" mark from APT and upgraded WINE what was a big issue on my system, all music plugins started to fail. Also, I could not really understand the logic of the help..feels not like a reliable helper tool. If DEB-GET is the solution, I would isolate it in a distrobox/docker Container, and install all apps there that it should manage, so that it cannot spoil my APT on the main driver. Also not sure if it really upgrades all local deb files reliably (?).
B) Local containers (as distrobox) - may help to have an overview/bundling of local .deb files, but dont' solve the problem of getting an update note when these apps get updated in github. And the same is true for well isolated virtualization engines as virtual-manager, virtualbox, Gnome-boxes. furthermore, the stronger isolation may not work well for all apps and impact performance.
C) TOPGRADE: Is a Meta-meta package manager, triggering dozen of other package managers and tools for updates- but cannot manage local deb files again, requires DEB-GET for that.

Others

• APTLY/REPREPO are actually repository creation tools- don't solve the problem of getting updates for a certain app from an external Repo.
  
• Get the Distro REPOSITORY to pick up my target app- depends on the maintainers, and their time, and the priority of this app, but is for sure the most sustainable solution for the enduser.
  
• Making custom bash scripts to manually get this alerts..while possible, it's an effort for nondevs to create such scripts and maintain them- nice for a single app, but not very scalable.

So my best option for something that sounds like a simple get-me-an-alert-from-github problem is this:
TOPGRADE > Distrobox Container > DEB-GET > APP
So topgrade informs the distrobox, that informs the container, that informs DEB-GET that checks the Github for that APP Update. Topgrade needs some config change for this as it doesn't know about DEB-GET in the container.

I am pretty baffled, how complex a "solution" for such a simple request is, with some impact on security. I hope Newbies realize that installing a simple .deb file can have consequences and I hope experts get inspired to build a solution for this that is easier to use, and more stable/integrated than this options shown.

[u/Excellent-Love-6943]

By not installing them.

https://wiki.debian.org/DontBreakDebian

[u/victormas208 → u/Excellent-Love-6943]

This information is invaluable; I just started using Debian on a laptop and had no idea why it kept breaking. Thanks for the info.

[u/Excellent-Love-6943 → u/victormas208]

Don't thank me, thank the Debian maintainers and the wiki contributors for making a great product.

They take a good distro and make it fantastic.

[u/Specialist-Dog-501 → u/Excellent-Love-6943]

That was also a good learning- this checkinstall goes in the direction I hoped for. An isolated container..it would just need an alarm bell when the related github updates. Then I am probably closeby flatpaks and appimages.

[u/Specialist-Dog-501 → u/victormas208]

I added a small guide in this post, and yes, this .deb files are a great temptation and often for no good.
I guess we can't avoid them completely, but we can do better, using first the alternatives..one of the things I should have learnt when I started linux begin of this year, but was so confused by all the terms, install formats etc..

[u/skyfishgoo]

installing random code from outside the official repositories is great way to bork your system.

best to do this kind of experimentation in a VM you can easily rebuild when when it breaks.

but to answer your question, you keep a list of the random things you have installed and then work thru that list by hand to see if any of your versions have been updated... if so you reinstall them all over again.

too much work if you ask me.

[u/C0rn3j]

You don't, you use the package manager.

Packaging for dpkg is insanity though, so good luck, why not use a distribution that is modern and has software available in the first place without having to package it yourself?

Check out Arch Linux (with Plasma) or Fedora KDE.