hi, thank you for your reply. On Wed, Apr 8, 2020 at 1:30 AM Julien Lepiller <jul...@lepiller.eu> wrote: > I think this is a bad idea, because it might break assumptions of the > mathematical model guix relies on. Not sure how to sync two stores > automatically. The "guix copy" command can be used to do that manually. Note > that guix publish will publish your whole /gnu/store, independently of how > items were obtained. > > If you use guix publish for things that were not built on the official build > farm, you need to have a look at guix --archive to generate key pairs and > authorize your personal substitute server. For items that were built on the > official build farm, it is enough to authorize the build farm, because these > items will be detected as identical, even if they come from a different > source.
Thanks, lazy evaluating "Invoking guix copy", it seems to be handy for each target package! > The manual has a section "the perfect setup" that should explain everything > if you want to contribute. > > Guix pull is indeed more or less a wrapper around git pull. The repository is > available in the store, but because of the mathematical model, it is > read-only and must not be modified. You can still use "guix edit foo" to open > the package definition of foo in your favorite editor. OK, I wil read that section throughly when time come. For now I have to used to its daily administration... >> If this is not for a contribution, the next best thing you can do is create >> a channel that allows you to share your modifications (or you can keep them >> private, but share them between your computers). > > Note that the guix-daemon is only there to build and download packages, it > doesn't know anything about available packages, etc. Your guix command does. > That allows each user on your system to customize the set of available > packages. Anyway, I use GUIX_PACKAGE_PATH and have managed to build small font package recipe. With some more, I will try it migrating to channel. regards, -- KURASHIKI Satoru
