1 |
On Wed, 2008-03-26 at 14:19 +0100, josé Alberto Suárez López wrote: |
2 |
> El mié, 26-03-2008 a las 13:57 +0100, Philipp Riegger escribió: |
3 |
> > I'm mostly interested in making GNAP usable and my proposal includes |
4 |
> > lots of tasks in GNAP and catalyst, of which i'd like to finish as many |
5 |
> > as possible and do some research on the rest. |
6 |
> > |
7 |
> > catalyst tasks: |
8 |
> > |
9 |
> > • Squashfs snapshot support |
10 |
> > I don't like it, that it takes so much time to unpack a new snapshot and |
11 |
> > it takes so much disk space to store it. Plan is: distribute tree |
12 |
> > snapshots as squashfs images, mount them directly into the workdir, |
13 |
> > use /mnt/distfiles and /mnt/packages instead of snapshot subdirectories. |
14 |
> |
15 |
> i like this can be usefull, the problem is how mcuh espace you need to |
16 |
> redistribute all sources we need (not only gnap-core srcs, i mean |
17 |
> extensions srcs too) |
18 |
|
19 |
This is all about catalyst. Catalyst takes a tree snapshot (/usr/portage |
20 |
as .tar.bz2), unpacks it somewhere and bind mounts it to its workdir. |
21 |
I'd like to get rid of this step, since it takes lots of time and wastes |
22 |
lots of disk space. I'm interested, what catalyst devs will say about |
23 |
it. |
24 |
|
25 |
> > • (Squashfs seedstage support) |
26 |
> > Maybe the same is possible for stages? A future plan for this could be |
27 |
> > to mount the squashfs image directly and use unionfs for the real work, |
28 |
> > but i have no idea how deleting files in such a setup works. Research is |
29 |
> > necessary here. |
30 |
> |
31 |
> i dont understand it well |
32 |
|
33 |
Same as above. Has nothing to do with GNAP, only catalyst. Imagine you |
34 |
want to build a stage2. You rsync stage1 to a workdir and build stage2 |
35 |
there. Therefore you have to unpack the stage1 somewhere and store it |
36 |
there. I want to get rid of this. |
37 |
|
38 |
> > • uclibc-cross-compiling support |
39 |
> > Cross compiling is hard, but it should be possible to build arch-uclibc |
40 |
> > from arch. Research, what needs to be done combined with the |
41 |
> > implementation, if possible. This would also make GNAP more flexible. |
42 |
> |
43 |
> this will be one of the biggest features so as you know is hard. |
44 |
|
45 |
I know, but i already know where to start, since i alredy got in touch |
46 |
with it last year. I just don't know, how many other problems there will |
47 |
be on the way. |
48 |
|
49 |
> > • Documentation |
50 |
> > In an email from some days ago i read, that documentation is planed for |
51 |
> > after the release. I could support this and proofread it, since i need |
52 |
> > the knowledge anyway. |
53 |
> |
54 |
> you mean gnap doc or catalyst doc? |
55 |
|
56 |
Catalyst, actually, but this could be extended to both. |
57 |
|
58 |
> > • Cross compiling research |
59 |
> > • Non-root builds research |
60 |
> |
61 |
> i think that is hard, you dont need root only for catalyst, other GNAP |
62 |
> operations need to be root. |
63 |
|
64 |
Why, exactly? There are reasons like "mounting stuff", "creating /dev |
65 |
files" and others, but maybe we can do that without root... |
66 |
|
67 |
> > GNAP tasks: |
68 |
> > |
69 |
> > • Code/Tree hosting, VCS |
70 |
> > I've done some work last year and that does only exist as some patches, |
71 |
> > since there is no central repository for GNAP development. First i'd |
72 |
> > like to establish one and move all existing resources there. |
73 |
> |
74 |
> yes, what about your google-code testing? |
75 |
|
76 |
I did not look into it, yet. If i slend half the week, testing it, i |
77 |
don't have an application for SoC. :-) |
78 |
|
79 |
> > • GNAP 2.1 |
80 |
> > There are some known and easy to fix bugs in GNAP 2.0. There have also |
81 |
> > been some code cleanups. The last thing is, that the current GNAP is not |
82 |
> > really usable, since the tree snapshot is so old, that most of the |
83 |
> > distfiles are not fetchable from mirrors or other places. So i'd like to |
84 |
> > make a new release, be it in the tree or in an overlay. |
85 |
> |
86 |
> you are right, but first we need and updated tree |
87 |
|
88 |
Yes, you're right. Maybe we could use the old tree, only fix security |
89 |
problems and ship that. Maybe we could package.mask it and use a |
90 |
development tree, that is only tested for building. Maybe some GNAP user |
91 |
(there have been some last year) is willing to share his tree and we can |
92 |
build on that. |
93 |
|
94 |
I'd like to look into an easy, mostly automated way of creating the |
95 |
tree, like a bunch of scripts and some documentation. If this is the |
96 |
only thing i get done, it was worth it. If i only get it started, then |
97 |
we are closer to being usable than we have before. |
98 |
|
99 |
> > • Reimplementation in python research |
100 |
> > Catalyst is written in python, maybe we could make better use of it if |
101 |
> > we reimplemented some parts of GNAP in python? This is just a research |
102 |
> > item, i'd like to look into it and form some statement about it. I'll |
103 |
> > probably not do it. |
104 |
> |
105 |
> i prefer to keep bash |
106 |
|
107 |
Again, i'll have to look into it. It's only research. There were some |
108 |
things i did not like in gnap, but i saw no other way to do it in such a |
109 |
low level language as bash. If i can do the scripts with half or one |
110 |
third of the lines of code in python, i would do that. If gnap and |
111 |
catalyst would merge in a way, that catalyst provides the tools and gnap |
112 |
only very very simple scripts and resources, that would be perfect, but |
113 |
gnap should not handle overlays, configurations and stuff, it should |
114 |
just pass them to catalyst. Much easier to do there, i think. But again, |
115 |
that are my current thoughts. |
116 |
|
117 |
Philipp |
118 |
|
119 |
-- |
120 |
gnap-dev@l.g.o mailing list |