Liliana Marie Prikler <liliana.prik...@gmail.com> writes: > I think you're making this more complicated than it needs to be. > checkout, authenticate, rebase*, merge* ought to have you covered. > > * you can authenticate after these if you're paranoid > >> We could create a script to do all the steps for us, but if and when >> it fails on whatever insane edge cases people are able to come up >> with, they're going to need to understand all the steps involved >> anyway. Abstraction is not a substitute for a clean underlying >> design. >> >> Also I just want to point out that rebasing /will/ change the >> history. >> The `guix pull` after every time you update your fork will need to be >> a force-pull (--allow-downgrades [1]). > No, it wouldn't. You would rebase those changes on top of what you > already have on those respective branches.
This has the slight issue that I can no longer easily answer a question
"is this commit in my fork", since I cannot search by the commit hash.
I admit it is not a question I need to answer often (last time was on
21st of October, CVE-2024-52867).
And merging also (and this is more interesting property) ensures that
*all* official commits are always present in my repository on the master
branch. So I can just use guix time-machine --commit without always
forgetting `-q' argument and having to do it second time.
I feel like the merging is a superior workflow for long-lived soft-fork,
expect the (here debated) issue with authentication.
>> Yes, to be clear, I'm talking about the use-case where your fork is
>> hosted remotely, and you or someone else needs to pull changes from
>> it. For example, my prospective use case would be quickly
>> bootstrapping Guix on a new machine - I build my own installation
>> image, and I'd want it to pull from my fork. I can include my
>> introduction into my installer, just like the official one. But if
>> the introduction changes before I use my installer, then the first
>> pull can't be authenticated.
> I don't see why in your particular use case you can not use a channel
> on top of Guix rather than replicating Guix itself. Now there might be
> some weird edge case I'm overlooking where you cut deep into the
> dependency graph and that makes sense, but I sure hope that's a rare
> edge case in and of itself.
As long as the changes are limited to packages, it is (mostly) fine, you
can get very far with (inherit) and various transformations.
However changes outside of that are not that rare. Few examples follow.
Anything modifying services is a problem. As far as I know, there is no
way to modify a service the way you can do with a package.
I carry a modification to nftables-configuration which adds (tables)
field so that I can do:
--8<---------------cut here---------------start------------->8---
(service
nftables-service-type
(nftables-configuration
(tables
(modify-nftables-tables %default-nftables-tables
(mod 'inet
(mod 'input
(rep 'allow-ssh
(if (and sshd-port open-sshd)
(allow-dport-snippet "tcp" sshd-port)
#f))))))))
--8<---------------cut here---------------end--------------->8---
It allows me to construct the firewall gradually, however I have not yet
decided whether I like the API or not (leaning towards "no"), so I did
not sent it upstream.
#71981 is open since July 7 and I am not aware of a way to work around
package->symbol deficiencies from a channel.
Then there is anything modifying any of the guix commands. #74832 is
over month old, and as far as I know, I am not able to fix guix-copy
from a channel. #72928 took over a month to merge, and again, not sure
how to patch guix-describe from a channel.
So, while I fully agree that package modifications *are* possible with
channel and are more common type of patch to carry, things that are
*not* possible with channel are (at least in my tree), while not as
frequent, definitely not a "rare edge case".
(Yes, I am aware I can just copy&paste the service code into my channel.
But at that point I am again just "replicating Guix", just by more
manual and error-prone means. And even for packages, adjusting system
configuration to use package from my channel, getting it merged and then
adjusting back to upstream is annoying chore.)
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
