Outdated is relative. You want stable builds with backported security updates and bug fixes and a new major release every year and half? Then stable is for you.

If you want a rolling release with occasional bugs then use testing/Sid.

Well, this is about 90% less stupid than pacstall (a bunch of scripts in a trench coat that plaster files around your fs) but it still kinda misses the point of Debian. Debian’s killer feature isn’t the package format as much as the curation, support and maintenance of the software in the Debian repos done by the community. I guess there is a use case for a grab bag of “other things” but there’s some significant downside potential if not used carefully.

You know… RHEL packages can be way more outdated than Debian.

I was just thinking the other day how nice it would be to port pamac into some more prod-oriented environments.

Looking through the docs, it appears to tick most of the boxes I’d want, will have to play with it in the coming days.

Have an upcoming project that will actually require some consistency and documentation, this might be useful.

I don’t mind building when necessary, but doing so is not calculated to communicate well with future me, so it’s not ideal.

I’m using MX Linux, it’s Debian based, but I don’t think packages are out of date? They have their own repo, test, backport.

But this makedeb is interesting nonetheless, I’ll bookmark it for when I want to try it.

I’m not on a Debian-based system but a recent experience w/ packaging a software as a DEB was quite eye-opening 😅 The format and the build process felt too cluttered (to me) and it wasn’t easy for me to wrap my head around it.

I’m happy that folks are working on alternatives ✌️

Another alternative could be Distrobox. Added benefit of the apps being sandboxed, and easily removed in case of issues. Downside is that you are eating up some space with some extra OS images.

I maintain a git repo of PKGBUILDs for use with makedeb. I use it to build binary packages for some programs which I like having newer versions (like neovim) and for some programs which I develop mostly for myself so they probably wouldn’t be accepted to official repos. I also host aptly repo with binary debs built this way.

To be sure that binary debs are “correct” (no broken dependencies, executables execute etc.), I created a program which runs makedeb in a Debian Docker container. It then sends build artifacts to aptly repo.

This workflow works flawlessly for me and I like it very much. I love the format of PKGBUILD files and I wish Debian modified its official tooling to support something else than the current official workflow.

Sometimes I have to rebuild some of the packages because there are breaking changes in Debian (e.g. new version of libc), but it isn’t a big deal thanks wrapper which can build all PKGBUILDs in my repo at once (although I may have to change packages versions so aptly accepts them).

I lint debs with lintian and there are some warnings introduced by makedeb, but most of them are easy to fix or workaround. Others are not important for me.

I don’t use MPR, because I don’t trust these scripts. I probably wouldn’t use makedeb to update some core programs or libraries (like Bash or systemd), but it’s great for non-core ones.

Also, I think that author of makedeb wanted to rewrite it in rust, possibly accepting breaking changes, but I don’t know what’s the status of this.

If you really want newer packages just use guix nix or flatpak

Lovely yet another package manager to add to the pile

Nice job team 👍