1 |
Hi everybody! |
2 |
|
3 |
We just created gnap-dev on Google Code: |
4 |
http://code.google.com/p/gnap-dev/ |
5 |
So please drop us (Andrey or me) a line and we will add you to the |
6 |
project. |
7 |
|
8 |
Furthermore we added gnap-dev as email address where all svn commits |
9 |
will be sent. This is ok, i guess, because this is a development list. |
10 |
And it is too much overhead to create an extra list for that. I filed a |
11 |
bug to get these messages whitelisted: |
12 |
https://bugs.gentoo.org/show_bug.cgi?id=223551 |
13 |
|
14 |
Next thing: I'd like to reorganize the repository and the ebuilds. I |
15 |
would like to split it the other way around than they are at the moment. |
16 |
I'd like to have: |
17 |
|
18 |
A) One ebuild called gnap, that installes all gnap_* scripts, |
19 |
documentation and examples. |
20 |
|
21 |
B) ebuilds of the form gnap-x86-uclibc, gnap-x86-glibc, |
22 |
gnap-x86-uclibc-hardened,... for each target we support containing a |
23 |
seedstage, build gnap base fs, maybe prebuilt extensions and the portage |
24 |
snapshot. We could controll the installation of prebuild extensions, |
25 |
prebuilt base fs and maybe other stuff with USE-flags. We could also |
26 |
split the portage snapshot into an extra ebuild in case multiple targets |
27 |
share the same one. |
28 |
|
29 |
A should have regular version numbers, like 2.0, 2.1, whatever, B should |
30 |
only have dates as version. |
31 |
|
32 |
Comments? |
33 |
|
34 |
Thanks, |
35 |
Philipp |
36 |
|
37 |
|
38 |
|
39 |
-- |
40 |
gnap-dev@l.g.o mailing list |