Gentoo builds every package from source on every user's machine, and when each user does an update, every package that changed gets rebuilt from source again.

So every Gentoo user that has a Python project that uses uv-build ends up having to rebuild uv-build, and then every Python project they have that uses it, every time uv-build pushes an update.

Other distros don't necessarily have quite the same problem because, if they include packages of Python projects, they don't normally track the build backend as a dependency. So if uv-build pushes an update, the distro would push an updated package for uv-build, but they wouldn't look at every Python project they package to see if it used uv-build as a build backend and rebuild it if it did. It's the "rebuild from source every time" aspect of Gentoo that forces that connection.

▲

jitl an hour ago | parent | next [-]

i guess gentoo is rolling-release, vs something like debian where every package is frozen in time (+ backports), and debian does seem to largely solve the coordination problem by making everything on the system use a fixed version of some package; with rare situations allowing >1 version of the package at a time.

my take on linux distros being annoyed by their own policies is that perhaps they should change the policy. in this case, perhaps they should pretend uv-build updates once a month or something.

for example, they seem to be fine doing a quick sed on pyproject.toml (https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/pa...) or patching stuff for compat (https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/as...)

This is what i mean when it seems typical for a distro to monkey around with packages and/or their build system. These were just the first two packages i clicked on in dev-python. maybe others are "pure upstream", but there's definitely the capability here to just... not have the problem?

	▲	simoncion 4 minutes ago \| parent \| next [-]
		> my take on linux distros being annoyed by their own policies is that perhaps they should change the policy. in this case, perhaps they should pretend uv-build updates once a month or something. Thing is, that won't work. From [0], with some more discussion starting at [1] > > I don’t understand why Gentoo needs to rebuild every single release of uv-build. > Because if you don't pin a version of uv-build in your project, that means "use the latest version available". Gentoo can't second guess you--even if it were able to verify somehow that the new version of uv-build that just got released will end up producing an identical wheel for your project as the previous version, without actually using the new version of uv-build. [0] <https://news.ycombinator.com/item?id=50077466> [1] <https://news.ycombinator.com/item?id=50077553>
	▲	pdonis 27 minutes ago \| parent \| prev [-]
		> i guess gentoo is rolling-release That's my understanding, yes.

▲

swiftcoder an hour ago | parent | prev | next [-]

> they don't normally track the build backend as a dependency... It's the "rebuild from source every time" aspect of Gentoo that forces that connection

I don't follow. This feels like Gentoo is mishandling build-tool dependencies.

Does Gentoo also recompile every C/C++ library in the dependency tree every time GCC pushes a minor version bump?

	▲	pdonis 25 minutes ago \| parent \| next [-]
		> This feels like Gentoo is mishandling build-tool dependencies. I would say it's doing what it believes is necessary for the Python ecosystem. The build backend is an explicit part of the specification of a Python project. > Does Gentoo also recompile every C/C++ library in the dependency tree every time GCC pushes a minor version bump? No, because C/C++ libraries don't have an explicit specification of the build tool to be used in their project, the way a Python project does.
	▲	everyflavourvms 42 minutes ago \| parent \| prev \| next [-]
		> I don't follow. I don't either. I used to run Gentoo for quite a few years in the past and build dependency updates would not trigger rebuilds of build-dependent packages. Rebuilding the entire system with a new GCC was recommended by the documentation, but there was nothing in Portage forcing it. Neither would you rebuild the system if, e.g. make got an update.
	▲	edoceo 42 minutes ago \| parent \| prev \| next [-]
		No, and not with clang or llvm or rust. When we get a new Golang tho, that does rebuild stuff built with Go. And big perl updates cause a rebuild for perl packages.
	▲	fuzzy2 an hour ago \| parent \| prev \| next [-]
		IIRC, rebuilds to GCC outputs are/were only recommended when the compiler "profile" changes. So basically whenever the ABI could no longer be guaranteed.
	▲	ForHackernews an hour ago \| parent \| prev [-]
		Strictly speaking, they should, right? Differences in GCC could produce differences in anything it compiles.

▲

BigTTYGothGF an hour ago | parent | prev [-]

Seems like a design flaw in gentoo that previously hadn't been an issue because build tools weren't being updated nearly as often as uv-build is.