1·
11 months agoI’m sure a lot of them existed 10 years ago but today it is a really good FS. I’m using btrfs on my server and laptop for a few years and had 0 issues. Today’s opinions on largly btrfs base on bugs and FUD from the past which is a shame.
Except RAID5 and 6. Don’t use them with btrfs :)
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.