1 |
Philipp Riegger wrote: |
2 |
> Good morning, |
3 |
> |
4 |
> I have some ideas for Summer of Code which i'd like to discuss with you. |
5 |
> |
6 |
> I'm mostly interested in making GNAP usable and my proposal includes |
7 |
> lots of tasks in GNAP and catalyst, of which i'd like to finish as many |
8 |
> as possible and do some research on the rest. |
9 |
> |
10 |
> catalyst tasks: |
11 |
> |
12 |
> • Squashfs snapshot support |
13 |
> I don't like it, that it takes so much time to unpack a new snapshot and |
14 |
> it takes so much disk space to store it. Plan is: distribute tree |
15 |
> snapshots as squashfs images, mount them directly into the workdir, |
16 |
> use /mnt/distfiles and /mnt/packages instead of snapshot subdirectories. |
17 |
|
18 |
Eh, I've never found unpacking a new snapshot to be all that cumbersome. While |
19 |
it probably wouldn't take much to implement this, I don't like the idea. At |
20 |
least, I'd never use it, since it would remove the ability to poke around in the |
21 |
snapshot_cache. |
22 |
|
23 |
> • (Squashfs seedstage support) |
24 |
> Maybe the same is possible for stages? A future plan for this could be |
25 |
> to mount the squashfs image directly and use unionfs for the real work, |
26 |
> but i have no idea how deleting files in such a setup works. Research is |
27 |
> necessary here. |
28 |
|
29 |
This isn't really feasible. |
30 |
|
31 |
> • uclibc-cross-compiling support |
32 |
> Cross compiling is hard, but it should be possible to build arch-uclibc |
33 |
> from arch. Research, what needs to be done combined with the |
34 |
> implementation, if possible. This would also make GNAP more flexible. |
35 |
|
36 |
If you want a uclibc stage, use a profile that has uclibc as the default |
37 |
virtual/libc provider. |
38 |
|
39 |
> • Documentation |
40 |
> In an email from some days ago i read, that documentation is planed for |
41 |
> after the release. I could support this and proofread it, since i need |
42 |
> the knowledge anyway. |
43 |
|
44 |
It's planned for some time in the future when the people who have the knowledge |
45 |
to write the documentation find the time and motivation. |
46 |
|
47 |
> • (Code cleanups) |
48 |
> I write this everywhere, but since i need a basic understanding, i have |
49 |
> to read (parts of) the source and maybe i find something worth |
50 |
> improving. |
51 |
|
52 |
Catalyst is definitely in need of code cleanups. However, that's just a result |
53 |
of a codebase that's changed hands multiple times over many years. We do random |
54 |
cleanups already as we encounter code that needs it. |
55 |
|
56 |
> • Cross compiling research |
57 |
> This is the continuation of the uclibc stuff with some plans on what |
58 |
> could be done how. |
59 |
|
60 |
Like I said on IRC, this is vapier's territory. |
61 |
|
62 |
> • Non-root builds research |
63 |
> Wouldn't it be nice if being root was not necessary for using catalyst? |
64 |
> I would like to look into the possibilities there and what is needed to |
65 |
> make it reality. |
66 |
|
67 |
Mostly, this would require the ability to do "random" bind-mounts and chroot. |
68 |
The only "sane" way to do this is to make catalyst suid root. |
69 |
|
70 |
-- |
71 |
Andrew Gaffney http://dev.gentoo.org/~agaffney/ |
72 |
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator |
73 |
-- |
74 |
gentoo-catalyst@l.g.o mailing list |