Arch Linux User Repository

Let's probably discuss this on the bcachefs-tools-git package page.

@intelfx, I believe the best course of action would simply be to revert the tools one to prior the split. It was still working fine for me. I only noticed the split because other users complained dkms weren't getting installed on the latest version.

@ticpu

Many are still using bcachefs-tools-cit for dkms since there wasn't any hard break to migrate users.

so the thing is, right now bcachefs-tools-git does not ship any DKMS at all, that's what I wanted to change in the first place.

Until my current situation stabilizes, I likely won't be able to maintain my other packages either. Most of them were just uploaded for personal use and weren't originally intended for public release. If anyone has any specific needs or questions regarding my other packages, please feel free to drop me an email.

Thanks to ticpu and intelfx for the feedback — you're both right. This package was originally something I maintained for personal use (I wanted to test bleeding-edge bcachefs features directly from the kernel tree, even ahead of bcachefs-tools). There's no good reason to push that workflow onto other users.

Due to personal circumstances, I won't be able to maintain this package for the foreseeable future. I'm orphaning it now. If anyone wants to pick it up, I'd suggest either switching the source to bcachefs-tools.git as intelfx mentioned, or folding it back into bcachefs-tools with DKMS support. Otherwise, feel free to let it go — bcachefs-tools-git with DKMS may already cover most users' needs.

I agree with intelfx that since it was split from bcachefs-tools it became all very confusing for existing users. Many are still using bcachefs-tools-cit for dkms since there wasn't any hard break to migrate users.

What was the motivation for the split? Tools and kernel module should always be in sync anyway.

Hi. Is there any specific reason for this package being the way it is, grabbing sources directly from bcachefs.git?

I talked to Kent on #bcachefs and he says that people are not supposed to use https://github.com/koverstreet/bcachefs.git directly. The testable snapshots are what's in in bcachefs-tools.git master.

@ticpu Thanks for the pushback.You’re right that this package is a special case.I changed course after additional package-specific build testing.

I’ve switched to a package-local fetch path in prepare() (plain git, not source=git+...): shallow + sparse checkout for fs/bcachefs only. That keeps the intended DKMS module output while avoiding full kernel-history downloads for first installs / CI / metered links.

Tradeoffs (explicit): - this is outside makepkg’s default VCS flow - network happens in prepare() - pkgver is now UTC commit timestamp + short hash (shallow history cannot provide stable full rev count) - epoch=1 is kept for upgrade-order continuity with already-published versions

Safety guards added: - fetch lock + timeout - retry + auto re-clone on broken local source state - package-time version drift check - symlink/type guard for module-version.c

So this is not a blanket policy for all -git packages; it is a targeted fix for this large-repo/small-module case. If makepkg gains stable native support for this case, I’m happy to switch back.

Thanks for the research, I see there has been some work towards a working solution but no fix we can use on all packages yet.

To clarify: the approach I'm suggesting doesn't use source=git+... or any makepkg VCS handling. It's plain git init + git fetch --depth=1 --filter=tree:0 + sparse-checkout in prepare(), just shell calling git directly. The GITFLAGS breakages don't apply here.

Allan's "write your own downloader" is exactly what this is. It downloads fs/bcachefs/ instead of the entire Linux kernel history. Same build output, a fraction of the data.

SRCDEST helps on repeat builds on one machine. It doesn't help first installs, CI, or metered connections. At some point "we can't do it in the framework" shouldn't be the reason users download gigabytes to build a 300KB module.

What are the impacts you see of doing the fetch ourselves in prepare() until a consensus is made for other packages? This package isn't pulling a small repo, it's the whole linux tree which is a very different concern than most others.

Incidentally, the PKGBUILD(5) manual (your ref #1) explicitly states that manual repository cloning in prepare() is the documented approach for cases where the standard source= handling doesn't fit.

@ticpu Thanks for raising this, and for sharing the logs.

You’re absolutely right that the initial sync can be painful on slower or metered connections.

I took another careful look at this before deciding. For now, I’m keeping this package on the default makepkg VCS path rather than adding package-local shallow/sparse fetch logic in pkgver() / prepare(). The main reason is compatibility and predictability: makepkg expects VCS handling through the standard flow [1], and shallow-related support that existed before was later removed after compatibility concerns [2][3][4]. In the latest pacman discussion I could verify (Work Item #307, note #note_423701, checked on March 1, 2026), native shallow support is still described as not currently planned [5].

So in the short term, I’m keeping the package aligned with that default behavior. For users who want to keep tracking the latest -git revisions, a persistent SRCDEST cache [6] lets makepkg reuse VCS sources between builds. This reduces repeated-download churn while still following upstream updates (the first full VCS transfer is still unavoidable).

If upstream makepkg behavior changes in the future, I’m happy to revisit this package.

References: 1. PKGBUILD(5): VCS sources in source=() 2. pacman commit: add GITFLAGS (2022) 3. pacman commit: remove GITFLAGS (2024) 4. MR !182 rationale for removing GITFLAGS 5. pacman Work Item #307 maintainer note (#note_423701) 6. makepkg.conf(5): SRCDEST