On Mon, May 18, 2020 at 07:23:12AM +1000, Begley Brothers Inc wrote:
> On Sun, May 17, 2020 at 11:21 PM Efraim Flashner <efraim@flashner.co.il>
> wrote:
>
> > On Sun, May 17, 2020 at 09:41:00PM +1000, Begley Brothers Inc wrote:
> > > Hi,
> > > We are now looking to build Linux kernels using Guix instead of Yocto.
> > We
> > > can't see any reason why the builds wouldn't be linux-libre. Ideally we'd
> > > like our effort to be accepted by upstream guix.
> > >
> > > However, being new to Guix we are still coming grips with the best
> > > practice(s) for what we would like to do.
> > > We've looked at Guix's linux.scm, and
> > > Efraim Flashner's post[1] is our primary reference - many thanks Efraim.
> >
> > I'd like to embarrassingly mention that I never actually booted any of
> > my custom kernels. My machine was a bit too slow to regularly compile
> > for some guess-and-check.
> >
>
> No worries. Something is better than nothing and that was very useful
> outline of possible alternatives.
>
> <snip>
>
> > 1) We did wonder if channels[2] were the way to go with each kernel x.y.z
> > > in its own branch and config files therein. Could anyone point us to
> > > packages that setup and use package specific channels?
> > > 2) Should we be aiming to provide a single package with multiple
> > parameters
> > > or is it better to provide a package for each kernel x.y.z, or some other
> > > partitioning. We'd likely want to script the package definition then -
> > > correct?
> >
> > I would probably start with one package each and then see how they could
> > be made to inherit from one another or grouped together. The way the
> > current make-linux-libre procedures work has grown quite a bit but they
> > should still mostly work as a starting point to add/remove bits for
> > customizing for your needs.
> >
> > I don't think I'd go with different branches. If you keep everything in
> > one branch then it's easier to deduplicate work between the different
> > variants.
> >
>
> That was our thought too.
> We're just wondering how best to get that branch content down to the users
> machine without them having to do anything.
>
> Thanks again.
>
One option would be to include a channels file in the repo that's setup
so that you can add to the README "this is where our customizations
live. In order to build an image, run 'git pull; guix pull
--channels=our-channel-file.scm --profile
~/.config/begley/current; ~/.config/begley/current/bin/guix
system build image.scm'". Then you can distribute the channels file you
Yes, that is somthing like what I had in mind, but would prefer to make it frictionless.
Channels have the disadvantage of requiring the user do somthing that adds no value - by that I mean we've asked them to do somthing generic, and haven't saved or gotten any benefit. For example if in creating the channel they gave data that allowed us to automagically build x,y and z when they `guix pull`, and they don't have to remeber to rebuild after `guix pull` then there has been some value add.
Right now I just don't see the value we could add - but we're still coming to grips with Guix.
Immediately I can see that our objection is eliminated if we build a package that adds a channel in the background.
Not sure if that is possible or in the spirit of Guix - we'd be altering one of their config files. How would we get their permission? etc. etc.
Thanks for the feedback.
--