[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mechanism for helping in multi-channels configuration
From: |
Christina O'Donnell |
Subject: |
Re: Mechanism for helping in multi-channels configuration |
Date: |
Sat, 3 Feb 2024 15:27:26 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 |
Hi Simon,
The wishlist is: provide a machine-readable description on guix-science
channel side in order to help in finding the good overlap between
commits of different channels.
It could be nice if instead of an hard error, “guix pull” could say:
« the channel ’guix’ needs to be at least at commit 1234abc ».
I was just thinking about these kinds of errors. It would also happen
between
channels when packages are split from a single file (eg. golang.scm to
golang-xyz.scm). Then channels immediately go out of sync as we're doing
continual releases. So, it wouldn't just be for time-machine. It's all a
bit too
fragile for my liking. I assume we won't be to frequent versioned
releases any
time soon..
A sketch of a solution might be:
1. Have a script that scrapes all the define-public symbols in every
file in
every package.
2. Have a script that determines the symbols needed by each file. (Macros
make this more difficult, but.)
3. Have both scripts have an incremental version that runs on diffs (for
performance).
4. Run this for every commit on every branch on every channel caching the
result.
5. Have a CI script keep this updated for new commits.
6. Have a server track incompatibilities.
For example, a 'definition-reference' could look like,
(definition-reference (commit-range start-hash end-hash)
file-path
identifier)
(definition-reference (commit-range "44b340d..." "06dba3b...")
"gnu/packages/golang"
'go-github-com-rs-xid)
Commit ranges makes the size of entries tractable (since package
probably aren't
getting moved / deleted / added very much).
Then use a hash table, (or trie or B+ Tree, or distributed hash table,
etc) to
go from identifier to definition-reference.
You would probably would also want to know commit date so you could
index on it.
That would let you find versions that supplied the identifier that are
as close
as possible chronologically to a particular version of a different channel
Now this isn't perfect (in case anyone was getting that impression ;):
- It won't have any idea about version incompatibilities.
- It couldn't trace renamed variables.
- And probably more.
Might be useful to additionally track package versions, but that might
run into
resource issues.
I'm thinking a Guile daemon backed by SQLite.. What do you think?
Full disclosure: I've got nothing lined up for the summer yet, so I'm on the
prowl for GSoC projects :)
Kind regards,
- Christina