Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12
Date: Fri, 01 Aug 2014 15:05:51
In Reply to: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 by hasufell
1 On Fri, Aug 1, 2014 at 10:35 AM, hasufell <hasufell@g.o> wrote:
2 > Rich Freeman:
3 > We only have the current implementation. So what you are saying is again
4 > just an idea without code. Voting on it now without a reference
5 > implementation will not result in anything useful.
7 Oh, I agree completely. I was trying to get at that in the last line
8 of my email.
10 >>> * They don't work with overlays.
11 >>>
12 >>> * They don't work with "resurrecting" packages in overlays.
13 >>
14 >> A lot of things don't work with overlays when it comes to changing
15 >> dependencies. The only reason we can do a lot of things in portage is
16 >> that we modify reverse deps along with the deps themselves.
17 >>
18 >> I haven't thought overlays through, and I'm willing to believe that
19 >> things break in odd ways with overlays. We may never be able to
20 >> handle dynamic deps properly with them.
21 >>
22 >
23 > Gentoo is becoming anti-modular. That is contradictory to our
24 > meta-distribution model.
26 Most of the overlay issues are with namespace. Overlays work great if
27 they are self-contained. If they depend on packages in the main
28 repository and those packages change, they will break.
30 >
31 > Not only, but also because of that we will lose a lot of people to NixOS
32 > in the next few years, I am pretty sure of that.
33 >
35 I don't see how they would solve the issues we have with overlays. I
36 don't know much about them but their approach to isolated builds
37 should at least help prevent dependency errors in the first place. If
38 package foo splits into two packages with different names, I don't
39 know how NixOS would prevent the need to update reverse dependencies
40 (unless it expresses things more granularly).
42 On the topic of dependency verification: one thing that probably
43 wouldn't be terribly hard to do is to configure our build jails based
44 on the declared DEPENDs. The jail already has both inclusion and
45 exclusion functionality - it is just set to include everything that
46 isn't explicitly excluded. If you fed the jail a list of everything
47 in DEPEND and @system then you should be able to reliably detect
48 missing DEPENDs.
50 But, that is more non-existent code.
52 What might be another approach would be to actually containerize or
53 use SELinux to enforce RDEPENDs when a package runs. I'm not sure if
54 NixOS purports to do that.
56 Rich