Liliana Marie Prikler <liliana.prik...@gmail.com> writes: [...]
> 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 :) [...] >> 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. You could probably get all these ideas to work. But try to put yourself in the shoes of someone who's just sent any of these patches. After putting in the hard work to fix an issue by modifying the upstream code, they now need to fix it AGAIN in a different way (via their channel). Imagine trying to reimplement something as complex as the bootloader subsystem rewrite [2] in your channel. If you're going to have to incorporate every contribution into your channel, you're heavily incentivized to only ever work on your channel, and never bother sending any patches to upstream. > Cheers > > [1] > https://git.ist.tugraz.at/clingabomino/clingabomino/-/blob/0.2.0/pkg/guix.scm?ref_type=tags#L30
