1 |
On Wed, 2008-03-26 at 09:17 -0500, Andrew Gaffney wrote: |
2 |
> Philipp Riegger wrote: |
3 |
> > • Squashfs snapshot support |
4 |
> > I don't like it, that it takes so much time to unpack a new snapshot and |
5 |
> > it takes so much disk space to store it. Plan is: distribute tree |
6 |
> > snapshots as squashfs images, mount them directly into the workdir, |
7 |
> > use /mnt/distfiles and /mnt/packages instead of snapshot subdirectories. |
8 |
> |
9 |
> Eh, I've never found unpacking a new snapshot to be all that cumbersome. While |
10 |
> it probably wouldn't take much to implement this, I don't like the idea. At |
11 |
> least, I'd never use it, since it would remove the ability to poke around in the |
12 |
> snapshot_cache. |
13 |
|
14 |
Well, i've been playing around with different snapshots over time and |
15 |
i've also been renaming the snapshot with each change to be able to undo |
16 |
a change. But in times of source control management, this should be |
17 |
unnecessary. |
18 |
|
19 |
The main point here seems to be, that we use catalyst in completely |
20 |
different ways. While i see /var/tmp only as catalysts working dir you |
21 |
work there. I usually try to do my change in the tree or overlay, tar |
22 |
it, copy it to /var/tmp and restart catalyst. |
23 |
|
24 |
> > • (Squashfs seedstage support) |
25 |
> > Maybe the same is possible for stages? A future plan for this could be |
26 |
> > to mount the squashfs image directly and use unionfs for the real work, |
27 |
> > but i have no idea how deleting files in such a setup works. Research is |
28 |
> > necessary here. |
29 |
> |
30 |
> This isn't really feasible. |
31 |
|
32 |
Do you mean in the way of "doable" or "usable"? I'm thinking of |
33 |
diskspace and speed, again. |
34 |
|
35 |
> > • uclibc-cross-compiling support |
36 |
> > Cross compiling is hard, but it should be possible to build arch-uclibc |
37 |
> > from arch. Research, what needs to be done combined with the |
38 |
> > implementation, if possible. This would also make GNAP more flexible. |
39 |
> |
40 |
> If you want a uclibc stage, use a profile that has uclibc as the default |
41 |
> virtual/libc provider. |
42 |
|
43 |
Is that possible? Last time i checked, i needed an uclibc seedstage, |
44 |
because otherwise catalyst wanted to build uclibc on a glibc system and |
45 |
they were blocking each other. |
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 |
So this might be an interesting task, which you would support? Or do you |
57 |
think, it's already done all the time, this is not needed? |
58 |
|
59 |
> > • Cross compiling research |
60 |
> > This is the continuation of the uclibc stuff with some plans on what |
61 |
> > could be done how. |
62 |
> |
63 |
> Like I said on IRC, this is vapier's territory. |
64 |
|
65 |
But if we keep it like that, it's questionable when it will be done. |
66 |
Maybe someone should look into vapiers thoughts and plans and work on |
67 |
that. |
68 |
|
69 |
Philipp |
70 |
|
71 |
-- |
72 |
gentoo-catalyst@l.g.o mailing list |