openkal 0.10 and the eight packages that move with it - #300
Merged
Conversation
A specification revision moves the whole graph or none of it: a version requirement here is exact and does not float up, and `openkal' is the shared dependency of every one of these packages. An implementation left at 0.9.0 while a consumer moves to 0.10.0 does not get its own older contract --- the two are irreconcilable and nothing resolves at all. - openkal 0.10.0 --- five declarations: kal_fs_lock/unlock, kal_process_spawn_bound, kal_task_parallelism, kal_fs_set_modified_at, kal_fs_capacity - openkal-linux 0.9.0, openkal-macos 0.7.0, openkal-windows 0.5.0 --- each implements them - openkal-opensbi 0.4.0, openkal-uefi 0.4.0 --- repins; neither provides an interface any of the five belongs to, so neither has anything to implement - openkal-musl 0.11.0 --- takes them up: real file locks, a bound spawn behind `execve', a real processor count, `statvfs', and a directory's time through the declaration rather than around it. Also three defects a consumer's test suite found, two of which needed no specification change - openkal-llvm-runtime 0.7.0 --- carries 0.11.0⚠️ Each version goes into all three platform tables, because a descriptor's platform table describes availability and not applicability --- which implementation applies is decided by a conditional dependency in the consumer. One table and not the others makes a package resolvable from one host and not another, which nobody notices until CI on a different runner goes red. Every sha256 is of the tarball GitHub serves, fetched at the moment the entry was written rather than passed in, and the byte-identical file was uploaded to gitcode and READ BACK AND COMPARED before this was committed --- an entry names one hash for both URLs, so a CN mirror built by repacking the tree would fail verification for every CN user and for nobody else. ⇒ `std-freestanding-alloc-kal` 0.1.3 is NOT here and cannot be: its CI resolves openkal 0.10.0 from the published index artifact, which republishes only when this branch lands. It follows in a second change once this one has.
Sunrisepeak
added a commit
that referenced
this pull request
Aug 30, 2026
… 0.10 move (#302) A repin: openkal 0.10 adds five declarations, none to an interface this package uses. Its twelve definitions are unchanged.⚠️ SEPARATE FROM #300 FOR A REASON, and the reason is worth recording. This package's CI resolves openkal from the PUBLISHED index artifact, which republishes only when this branch lands --- so while openkal 0.10.0 existed as a release but not yet as an index entry, its CI could not go green no matter what the package said. The batch had to land first and this had to follow it. There was no ordering that put both in one change. ⭐ It was also found by sweeping the index for every file that names openkal, rather than by working outward from the packages already being changed: `std-freestanding' requires this one as `^0.1.0' and so picks the bump up on its own, so nothing in the openkal dependency graph points at it. A sweep finds it and a traversal does not.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A specification revision moves the whole graph or none of it: a version
requirement here is exact and does not float up, and `openkal' is the shared
dependency of every one of these packages. An implementation left at 0.9.0 while
a consumer moves to 0.10.0 does not get its own older contract --- the two are
irreconcilable and nothing resolves at all.
kal_process_spawn_bound, kal_task_parallelism, kal_fs_set_modified_at,
kal_fs_capacity
implements them
interface any of the five belongs to, so neither has anything to implement
execve', a real processor count,statvfs', and a directory's time throughthe declaration rather than around it. Also three defects a consumer's test
suite found, two of which needed no specification change
platform table describes availability and not applicability --- which
implementation applies is decided by a conditional dependency in the consumer.
One table and not the others makes a package resolvable from one host and not
another, which nobody notices until CI on a different runner goes red.
Every sha256 is of the tarball GitHub serves, fetched at the moment the entry
was written rather than passed in, and the byte-identical file was uploaded to
gitcode and READ BACK AND COMPARED before this was committed --- an entry names
one hash for both URLs, so a CN mirror built by repacking the tree would fail
verification for every CN user and for nobody else.
⇒
std-freestanding-alloc-kal0.1.3 is NOT here and cannot be: its CI resolvesopenkal 0.10.0 from the published index artifact, which republishes only when
this branch lands. It follows in a second change once this one has.