191–198 of 198 posts
>"Self-contained" I love that whole paragraph. And in general prefer their philosophy.
Debian doesn't go far enough on that point, the folks at GNU Guix and Bootstrappable Builds are getting to the point where they can build the entire distro from source starting with only ~500B of manually written machine code. https://bootstrappable.org/ https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...
Earlier quoted context omitted.
I think either approach makes sense depending on who you are. If your goal is to distribute software across multiple distros and operating systems, bundling dependencies makes sense. If your goal is to maintain a distro, shared libraries that you can apply a security patch to exactly once is obviously better. But these are two different people with either goal.
This is how I ended up with three separate the Gimp installs on my system. A deb a snap and a flatpack. And I still can’t get plugins to work.
You gave up one package system too early. I managed to get the Python 2 plugins working with AppImage bundle someone linked to on some forum.
Earlier quoted context omitted.
The spec for .deb packages is in the deb(5) manual page: https://manpages.debian.org/bookworm/dpkg-dev/deb.5.en.html
That's not a 'spec' - it's a vague description of the archive names.
Earlier quoted context omitted.
You seem to assume that Debian users are hapless and are ending up in these situations by accident. That's not true. Most users choose Debian's model because they want to use software maintained by people who care about their use cases. They use old versions of software by choice, because they want a platform that doesn't change under their feet. Others use Debian or something Debian-based because it is popular, but…
I was a contributor to a small Linux desktop application ages ago. We absolutely had a regular flow of hapless users who installed the Debian-provided package and reported bugs that either never existed in upstream builds or had been fixed months before. I believe the situation was that Debian had packaged an obsolete version of the software for stable because of a misunderstanding of the versioning system. When upst…
I won't link to it, as he blocks links coming from here...
Earlier quoted context omitted.
If you "just have a binary" then you aren't compiling from source, which means you can't make modifications to that binary easily, which Debian wants to be able to do to fix security issues and other bugs. There is a large range of documentation, everything from the simple to the more advanced to different packaging niches. The large amount of docs makes that harder to navigate though, and a lot of stuff is moving to…
Having to use these automatic packaging tools is exactly my gripe. I don’t want to have to rely on whatever scripts someone conjured up if it’s not supported by the distro itself. I agree it always makes sense to have sources involved for packages that are getting distributed as part of the distro, but what if I want to just deploy my product on a server without the sources?
If you want to make external packages (such as those that don't come with source), then you can just use `dpkg-deb --build` or one of its many wrappers to shove the binary into a .deb.
Earlier quoted context omitted.
That's not a 'spec' - it's a vague description of the archive names.
It and the other manual pages linked from it contain everything you need to make a .deb from scratch.
Earlier quoted context omitted.
It and the other manual pages linked from it contain everything you need to make a .deb from scratch.
I can’t find it right now, but the Debian docs explicitly indicate that you shouldn’t do that because the internal format is not stable. It has changed significantly in the past, and the only “supported” way to do it is with the official Debian tools
The only significant future change I can think of is the mtree stuff, which would add an additional metadata file to .deb files.
There are several warts in the .deb file format that the dpkg folks aren't fixing because of compatibility concerns.
https://wiki.debian.org/Teams/Dpkg/RoadMap https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking https://wiki.debian.org/Teams/Dpkg/TimeTravelFixes