Re: Non-committers can't keep authenticated forks updated

[Liliana Marie Prikler]

Am Donnerstag, dem 16.01.2025 um 00:01 +0100 schrieb Tomas Volf:
> Liliana Marie Prikler <liliana.prikler@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).
You could solve this by embedding an "upstream-commit:" trailer, but
that is an admittedly cursed transformation that no longer maps to a
single rebase, I admit.

> 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.
In my personal experience, time-machine breaks with third-party
channels all the time, so `-q` is probably good advice anyway.  But
yeah, that's a valid concern.

> 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.
You can roll your own service definitions, but it does become harder
when you want to keep all changes to that service from master as well.
But `(use-modules (my-channel services nftables))` should pull that
nftables code :)

> #71981 is open since July 7 and I am not aware of a way to work
> around package->symbol deficiencies from a channel.
I mean, the right thing would be to address #71979, but I don't see
that being done either.  Ludo's fix is merely lexicographic and thus
breaks with directories that aren't simply ".".

> 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.
Have you considered extensions?

> (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.)
You could code your channel in a way that it serves upstream stuff
either silently or with a deprecation warning if a particular package
is requested.  Not a channel, but [1] illustrates my point.

Cheers

[1] 
https://git.ist.tugraz.at/clingabomino/clingabomino/-/blob/0.2.0/pkg/guix.scm?ref_type=tags#L30