On Debian-based distros, when an app is available as a DEB or an AppImage (that doesn't self-update), but no APT repository, PPA or Flatpak, the only option is to manually download each update, and usually manually check even whether there are updates.

But, what if those would be upgraded at the same time as everything else using the tools you're familiar with ?

dynapt is a local web server that fetches those DEBs (and AppImages to be wrapped into DEBs) wherever those are, then serves these to APT like any package repository does.

I started building it a few months ago, and after using it to upgrade apps on my computers and servers for some time, I pre-released it for the first time last week.

The stable version will come with a CLI wizard to avoid this manual configuration.

Feedback is welcome :)

top 50 comments

sorted by: hot top controversial new old
[–] 44 points 2 years ago (2 children)

Obtainium but for Debian, nice

  • source
  • hideshow 4 child comments
  • [–] 15 points 2 years ago (2 children)

    Such a security risk though, but still better than curling scripts into sudo

  • source
  • parent
  • hideshow 4 child comments
  • [–] 10 points 2 years ago* (last edited 2 years ago) (1 child)

    If I'd decide to implement something like this, I'd consider two options: local repo with file:// scheme or custom apt-transport. HTTP server is needless here. (But I'll never do this because I prefer to rebuild packages myself if there's no repo for my distro.)

  • source
  • hideshow 2 child comments
  • [–] [S] 9 points 2 years ago (2 children)

    local repo with file:// scheme

    With that, I couldn't trigger a download when apt update is ran, I could only do a cron, i.e. a delay, that I do not want.

    custom apt-transport

    I thought about that, but found no documentation on how to do it. If you have any, I'm interested.

    Even just finding documentation on how to generate DEBs and APT repository metadata files was very hard.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 7 points 2 years ago (2 children)

    It is documented in libapt-pkg-doc (/usr/share/doc/libapt-pkg-doc/method.html/index.html).

  • source
  • parent
  • hideshow 4 child comments
  • [–] [S] 4 points 2 years ago (1 child)

    Yeah, I don't have the skill for this. I'd be very happy if someone else would make this, but if not then I'm sticking to HTTP.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 2 years ago (2 children)

    I went way down the rabbit hole on this one and ended up with a proof of concept that's probably close enough to be able to wire it up: https://gitlab.com/-/snippets/3745244

    I guess it didn't end up too much code, but I'm not entirely sure it's worth it.

    (it's after 3 AM? oh no what have I done)

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 2 years ago* (1 child)

    differently hacky idea:

    since you do end up with all the packages in a repository on the filesystem, and you just want to have it do this just-in-time updating when the Packages file is accessed...

    what if you list it as a normal file apt source, but you make the Packages file a FIFO?

    it's a cursed idea but I'm not sure it is any less cursed than the other options we've come up with.

    it may or may not help to have systemd.socket manage creating the FIFO and running the service.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 2 years ago (1 child)
  • [–] 7 points 2 years ago* (5 children)

    This might be for the better, but Discord was so infuriating about updates and forcing you to download them what felt like 50% of the time I opened it, I gave up and just use it in Ungoogled Chromium now. I'm pretty sure within a few months I ended up having 15+ debs of Discord in my Downloads folder.

    For anyone else trying to use the native Discord app on Debian, I think they'll find this a major treat.

  • source
  • hideshow 7 child comments
  • [–] [S] 5 points 2 years ago (1 child)

    Discord not automating downloads of DEBs is one of the reasons motivating me to do this.

    Personally I need the desktop client because I mod it with plugins that are so useful that I can't do without these anymore.

    Alternatively, there are third-party repositories here and here.

    There still is delay between Discord releases and repository updates so I still believe dynapt to be the better solution.

  • source
  • parent
  • hideshow 2 child comments
  • load more comments (3 replies)
    [–] 7 points 2 years ago (3 children)

    Sorry to be that guy, but this sounds like a cybersecurity nightmare. While everybody was busy to come up with schemes that make absolutely sure that only trusted sources can update a system to avoid having malicious players push their code to users, this one just takes any rando's pile of whatever and injects it straight into the system's core? Like, that doesn't sound like a good idea.

  • source
  • hideshow 6 child comments
  • [–] [S] 12 points 2 years ago (9 children)

    Well, I'm just automating what people currently have to do manually : visit GitHub and download DEB and install DEB.

    If the automated process would be dangerous then the manual process also would be, and that would be on the maintainer for not providing an APT repository or a Flatpak, not on the user for just downloading from GitHub.

  • source
  • parent
  • hideshow 9 child comments
  • load more comments (9 replies)
  • [–] 7 points 2 years ago* (2 children)

    Looks great, well done.

    Personally, the deb-related annoyance that I have encountered most often in recent years is that there is an APT repo but I have to jump thru hoops to add it. An example is signal-desktop, where the handy one-click installation goes like this:

    # 1. Install our official public software signing key:
    wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg
    cat signal-desktop-keyring.gpg | sudo tee /usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null
    
    # 2. Add our repository to your list of repositories:
    echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https://updates.signal.org/desktop/apt xenial main' |\
      sudo tee /etc/apt/sources.list.d/signal-xenial.list
    
    # 3. Update your package database and install Signal:
    sudo apt update && sudo apt install signal-desktop
    

    Why does Debian-Ubuntu not provide a simple command for this? Yes there is add-apt-repository but for some reason it doesn't deal with keys. I've had to deal with this PITA on multiple occasions, what's up with this?

  • source
  • hideshow 4 child comments
  • [–] 1 point 2 years ago* (1 child)

    Why does Debian-Ubuntu not provide a simple command for this?

    You aren't supposed to add repos. Ever. https://wiki.debian.org/UntrustedDebs

    Apt is not built with security in mind, at all. The partial sandboxing it does do is trivial to bypass. Adding a repo is basically a RAT Trojan on your computer.

    An example is signal-desktop

    Yeah don't use signal. They restrict freedom 3 by making distribution difficult. Thats why they trick you into using their RAT repo.

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842943

    The least bad option is the unofficial flatpak.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 2 years ago (1 child)

    Apt is not built with security in mind, at all. The partial sandboxing it does do is trivial to bypass. Adding a repo is basically a RAT Trojan on your computer.

    OK. I suppose this is the correct answer.

    The least bad option [for Signal] is the unofficial flatpak.

    Unless I'm missing something, here we will disagree. Secure or not, FOSS principle-respecting or not, if I'm choosing to install software by X then I'm going to get it straight from X and not involve third-party Y too.

  • source
  • parent
  • hideshow 1 child comment
  • load more comments (1 reply)
  • [–] 3 points 2 years ago (1 child)

    Is that autotiling on cinnamon? Didn't know it could do that

  • source
  • hideshow 2 child comments
  • [–] 3 points 2 years ago (1 child)

    I like it. Wonder if this could be retooled to work on rpm-ostree systems, because any layered packages installed from RPM files have the same limitation of needing to be manually upgraded.

  • source
  • hideshow 2 child comments
  • [–] 3 points 2 years ago (1 child)
  • [–] 1 point 2 years ago (1 child)

    This is somewhat re-inventing some things Ansible can do, which is download and install software whether it has a formal or informal source.

    Ansible is the automation I use to manage personal and professional servers.

  • source
  • hideshow 2 child comments
  • [–] 1 point 2 years ago (1 child)

    Neat project!

    While this might not solve all of your use cases, did you consider a tool like mise?

    Theres a number of other options out there such as asdf-vm and others who's names I can't recall. I recently moved from asdf to miss but its a great way to install things on different machines and track it with your dotfiles, or any other repo you want to use. Mise has tons of configuration options for allowing overrides and local machine specific versions.

    It won't tie into apt for your upgrades but you could just alias your apt update to include && mise up.

  • source
  • hideshow 2 child comments
  • [–] 1 point 2 years ago

    I would test this out on termux. It's annoying to have very limited supported programs.

  • source
  • load more comments
    view more: next ›