Hi, "devmsv" <[email protected]> writes:
> - Do Guix developers just hack in ~/src/guix, add their own > packages/updates, and commit them later? in this case: > > - How do they deal with channel authentication, merges, and rebasing > with Guix’s master branch? I just have my own fork[0] that I merge the Guix proper into regularly. I simply call `./etc/update-fork' and let the scripting do the rest. Some people use rebase, but I find it sub-optimal, because it forces you to pass `--allow-downgrades' flag to `guix pull'. Also, rebase hell is real. So merge (with a proper merge commit) is what I have decided to use to keep up with the upstream. Guix historically has somewhat mixed story on time it takes to merge patches — albeit lately it got much better, I am grateful to Andreas. And that assumes you even can send patches — some (well, just me ^_^) do not (want to) have a Codeberg account. So (if you are not a committer), it can be a bad experience to wait (sometimes long time) before the fix you need is merged, so having your own tree is a must (in my opinion). Having own tree also gives you the flexibility to tailor the Guix to your needs. For example, I have modified command line parsing in my Guix fork to support `--expose ~/foo' instead of the upstream's `--expose=$HOME/foo'. This type of change cannot be done in a channel, and it cannot be contributed upstream, since it is backwards incompatible. The fork is over 2 years old now and while there occasionally are merge conflicts, it is not that bad. All in all, I would say this is pretty painless approach. Downside is that having an authenticated fork is not currently possible with Guix's security model unless you are a committer, so some patching is required. There is a script[1] to make your own fork, if you need it — I did not test it in some time, but it probably still works. Hope this was of use, Tomas 0: https://git.wolfsden.cz/guix/ 1: https://git.wolfsden.cz/guix/tree/etc/fork-guix -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
