[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "guix potluck", a moveable feast

From: ng0
Subject: Re: "guix potluck", a moveable feast
Date: Sat, 1 Apr 2017 16:01:53 +0000

Christopher Allan Webber transcribed 1.8K bytes:
> Andy Wingo writes:
> > Hi!
> Hi!
> > needs to be isolated from other hosts because it will
> > load potluck.scm files from untrusted sources; we hope the sandbox works
> > but we need a bit of defense-in-depth.
> Well now I see the motivation behind (ice-9 sandbox) ... :)
> > As I mentioned, I think it would be nice to be able to install some
> > potluck packages directly from git, without requiring those packages to
> > make releases and update the potluck.scm.  But until then, we can make
> > it so that the source is fixed in the potluck.scm as it is with other
> > Guix packages, and therefore that any update to potluck.scm in the
> > source git branch registered with constitutes a new
> > release which replaces the old one.  A developer should signal
> > about the update via a re-invocation of "guix potluck
> > add".  Maybe "guix potluck add" could remember the branch, dunno.
> >
> > Anyway!  The result of the "guix potluck channel-manager" is a stream of
> > guix modules as a continually updated git tree -- a guix channel.  I am
> > thinking that we need to rewrite these files to be more "normal" -- like
> > starting with a (define-module), but a #:pure module and an appropriate
> > set of imports to enforce the sandbox.  We should be able to compile
> > this module, to prevent the potluck channel from slowing things down.
> > So basically the channel-manager rewrites the potluck.scm files.
> It sounds nice!
> One challenge though... what do we do about multiple channels
> introducing version skew?  (Maybe I'm abusing that term?)  This isn't
> something we've dealt with before in Guix... if my channel adds
> something that depends on your channel's package definition, do I
> explicitly set a revision for your channel?  Otherwise else, your
> channel could change as you upgrade your software version, and that
> might unexpectedly break my channel...
I think there's something we can learn from Gentoo here.
You might or might not know their 'overlays' (I don't know the exact
gentoo rfc when they introduced them but it's been very long ago).
They do this kind of thing. They have no opinion other than that
'portage', in Guix terms 'master branch at savannah', takes the highest
priority by default. You can explicitly change this.
If you start using a specific overlay and use a software recipe from it
which does exists in multiple overlays, it's like this:
- if you don't edit the specific file which tells portage about this
  recipe, it picks the highest stable version.
- if you get rid of stable and allow everything, it picks the highest
  version and has no opinion from where it comes.
- if you specifically point out the overlay for it, it picks the version
  from there, no questions asked. well actually it asks questions if you
  tell it to do so ;)

So I think we could have some way to define the priority of the channel,
a value to define stable / unstable (similar to Gentoo's "experimental"
and "official" classification of overlays).

No warranty that this is accurate, I tried to explain Gentoo overlays
without assuming too much or explaining too much of it.
In case I misunderstood the question, enjoy your 2 minutes of
'Things Gentoo did excellent'.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]