Obtainium but for Debian, nice
Thanks !
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.)
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.
It is documented in libapt-pkg-doc
(/usr/share/doc/libapt-pkg-doc/method.html/index.html
).
In an APT package OMG 😂
I found an online version though, which I would never have found through my search engine (and on a site that doesn't even support HTTPS) 😅
Looks like difficult reading too 😭
Thanks anyway.
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.
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)
Why the OOP structure and syntax ? Sorry but it makes it difficult to read for me even in my own language 😅
I'll look into it, thanks !
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.
What's a FIFO ?
I've also looked into VFS but found nothing I'd have the skills to implement. 😅
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.
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.
Well, I’m just automating what people currently have to do manually : visit GitHub and download DEB and install DEB.
Yeah. You should never do that. Like ever. Build from source; or use a vendored tarball. https://wiki.debian.org/DontBreakDebian
.deb is a terribly insecure nightmare thats held up by the excellent debian packagers, gpg , and checksums, and stable release model. don't use .deb files.
I'm and end user working for end users.
I’m and end user
Yeah, we all are. What's your point?
End users are also developers. All computer users are developers. You are developing.
user working for end users
By making a script that lets me get backdoors and shitty packages with ease? The linux package distribution system is a nightmare, Debian is the least bad approach. There is basically always a better option to using a .deb file. If you come across something that isn't packaged, I recommend Flatpak, building from source (and installing unprivileged), or using the developers vendored tarball (installing unprivileged).
https://wiki.debian.org/SecureApt
By using local .debs you lose the benefit of:
Reproducible builds
GPG checksums
Stable release model
debian security team
My point is that I'm working a solution for end users.
The solutions you're offering are not user-friendly.
It’s a cool concept, but automation breeds laziness (by design, to an extent) and lazy end users tend to shoot themselves in the foot. So it isn’t great for security, but it also isn’t that much worse for security :)
Since some people with money tend to be litigious, and, of course, I am not a lawyer, I would advise a warning message (or part of the license if you don’t want to muck up your CLI), if you don’t have one, to force the user to accept and acknowledge that the software they are installing using this tool is not verified to be safe.
How is the manual step more secure though ?
What does the user do before downloading a DEB that makes that gap between manual and automated ?
I'd be willing to try and reproduce that, but I don't see anything.
No matter where you install from, you have to trust the source. Indeed, you have to trust every step in the supply chain.
If you are getting your code straight from the author, you are eliminating an exploit that’s introduced by a compromised account of a packager.
Carry on.
I see it more as a local repo. Like, setup the repo to do what you would have done manually so that you don't have to do it on multiple computers. I could be misunderstanding it though.
You understand perfectly.
Neat! Thanks for sharing!
Thank you for your appreciation !
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?
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.
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.
Thanks, and agreed !
Fortunately, copy/pasting works and you only have to do it once.
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.
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.
Personally I need the desktop client because I mod it with plugins that are so useful that I can’t do without these anymore.
Discord client modifications are against the Terms of Service. https://www.gnu.org/philosophy/free-sw.en.html
I don't care.
Just use the flatpak?
I didn't know there was one, that's interesting, thanks.
Updates must still be delayed because of being third-party though.
This is 100% of the reason that I use the discord flatpak.
Is that autotiling on cinnamon? Didn't know it could do that
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.
I don't know anything about RPMs, but if you or anyone is familiar with it then perhaps !
Sorry to ask, but isn't this basically the same thing as apt-cacher-ng?
Sorry to ask
Don't be. I would love to know that an existing and more experienced program does what mine does.
I've been looking for it myself for a long time before deciding to build it.
isn’t this basically the same thing as apt-cacher-ng?
Here's what I'm reading :
Apt-Cache-ng is A caching proxy. Specialized for package files from Linux distributors, primarily for Debian (and Debian based) distributions but not limited to those.
A caching proxy have the following benefits:
- Lower latency
- Reduce WAN traffic
- Higher speed for cached contents
+------------+ +------------+ +------------+ | Apt Client | <------+ Apt Cache | <------+ Apt Mirror | +------------+ +------------+ +------------+
So, not the same thing.
It locally mirrors existing repositories containing existing packages, it doesn't locally create a new repository for new packages from standalone DEBs.
OK yeah, I wasn't sure if it had a way to collect debs from other sources. I've been using it for years to locally cache the standard Debian repos so I don't need to re-download packages every time I update my various servers and VMs, but I haven't really tried using it for anything beyond that.
Great idea!
Thanks !
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
.
I would test this out on termux. It's annoying to have very limited supported programs.
Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0