Saw the post here regarding CentOS’s off-springs and a couple of people brought up the excellent point of: why play with fire? Let’s just stick to Debian.
The only disadvantage I currently see is the outdated packages, and I’m curious whether makedeb solves them. Does anyone here use it regularly? How stable and comfortable is it? Did you write your own PKGBUILDs?
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.What do you mean by “plastering files around your fs”?
You know… RHEL packages can be way more outdated than Debian.
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 ✌️
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 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 👍
You clearly didn’t read did you:
The makedeb Package Repository (abbreviated MPR) is a user-maintained repository of build files (PKGBUILDs) that can be built with makedeb and then installed with APT.