1 |
Dnia 2014-07-02, o godz. 10:44:16 |
2 |
William Hubbs <williamh@g.o> napisał(a): |
3 |
|
4 |
> All, |
5 |
> |
6 |
> I'm moving to a new thread since the discussion has moved away from just |
7 |
> a sub profile for no-multilib. |
8 |
> |
9 |
> On Wed, Jul 02, 2014 at 09:30:50AM -0400, Rich Freeman wrote: |
10 |
> > On Wed, Jun 25, 2014 at 4:01 PM, Andreas K. Huettel |
11 |
> > <dilfridge@g.o> wrote: |
12 |
> > > Am Mittwoch 25 Juni 2014, 15:11:40 schrieb Rich Freeman: |
13 |
> > >> On Wed, Jun 25, 2014 at 2:44 PM, Michał Górny <mgorny@g.o> wrote: |
14 |
> > >> > Long story short, doing anything to Gentoo profiles is utter pain |
15 |
> > >> > and comes with random breakage guarantee. Therefore, I'm asking -- nuke |
16 |
> > >> > those damn profiles, and start over! The current situation is |
17 |
> > >> > completely unmaintainable. |
18 |
> > >> |
19 |
> > >> ++ |
20 |
> > >> |
21 |
> > >> But, would it make sense to just go the Funtoo route with "mix-ins." |
22 |
> > > ++ |
23 |
> > > |
24 |
> > > this is what we've been just discussing on the irc channel |
25 |
> > |
26 |
> > So, not wanting this to die on the vine. |
27 |
> > |
28 |
> > If we did the mix-in approach, would we just follow the example of Funtoo? |
29 |
> > |
30 |
> > They use an arch profile, a stability profile (~arch vs arch), a |
31 |
> > "flavor" profile (core, minimal, desktop), and then users can layer as |
32 |
> > much other stuff on top of that as they want (gnome, kde, multimedia, |
33 |
> > etc). |
34 |
> |
35 |
> I think this could work for us as well, or something similar anyway. |
36 |
> |
37 |
> For those who are curious, I am including the link to the flavors and |
38 |
> mix-ins descriptions from the funtoo site. [1] |
39 |
|
40 |
It's not that easy. As you can see on that site, they're supporting |
41 |
much less variants than Gentoo does. In particular, they don't seem to |
42 |
support non-GNU/Linux at all. No Prefix, no Hardened, no FreeBSD. |
43 |
|
44 |
I was thinking about modularization a bit and the main issue is |
45 |
handling intersecting profiles. As you can see in Funtoo, it already |
46 |
starts with the 'build' flavor -- they're pretty much applying a cheap |
47 |
hack (ACCEPT_KEYWORDS="${ARCH}") but such hacks can't cover all our |
48 |
needs. |
49 |
|
50 |
A simple example is CHOST. The value of CHOST depends on the arch, |
51 |
often ABI, kernel, libc. Of course, we could hack this around by |
52 |
creating some intermediate variables and merging them afterwards. |
53 |
But not everything can be hacked around like this. |
54 |
|
55 |
I don't feel like we ought to vote on something like this without |
56 |
understanding most of the current profiles. And I'm afraid there are |
57 |
only few people who have any idea about the current profile |
58 |
structure... |
59 |
|
60 |
> > Do we want to do things the same way? |
61 |
> > |
62 |
> > Some things to think about include multilib (just another arch?), |
63 |
> > systemd, and usr-merge. I'm not saying that we need to implement any |
64 |
> > of that stuff completely - but when planning the profile layout we |
65 |
> > should at least consider whether it will handle things like this in |
66 |
> > the future. Should some types of profiles be only additive? Etc... |
67 |
> |
68 |
> I see systemd and multilib as mix-ins, like the ones you mentioned |
69 |
> above. |
70 |
|
71 |
Multilib won't work as Funtoo-style mix-in for the simple reason it |
72 |
relies on heavily on the architecture in use. |
73 |
|
74 |
-- |
75 |
Best regards, |
76 |
Michał Górny |