1 |
Author: vomacko |
2 |
Date: Mon Jul 7 07:31:53 2008 |
3 |
New Revision: 130 |
4 |
|
5 |
Added: |
6 |
wiki/gnap_glsa_proposal.wiki |
7 |
|
8 |
Log: |
9 |
Created initial glsa integration description page |
10 |
|
11 |
Added: wiki/gnap_glsa_proposal.wiki |
12 |
============================================================================== |
13 |
--- (empty file) |
14 |
+++ wiki/gnap_glsa_proposal.wiki Mon Jul 7 07:31:53 2008 |
15 |
@@ -0,0 +1,9 @@ |
16 |
+#summary One-sentence summary of this page. |
17 |
+ |
18 |
+= Introduction = |
19 |
+Here, I would like to describe initial thoughts about integration of |
20 |
GLSA checks into GNAP and further steps in this area |
21 |
+ |
22 |
+ |
23 |
+= Details = |
24 |
+ |
25 |
+I would like to integrate glsa_check ( both update ability and |
26 |
notification ability) for existing gnap_make tool. We should be able to |
27 |
update/regenerate existing core builds and if possible use also |
28 |
extensions for that. We can make separate script with only "gnap_glsa" |
29 |
functionality, with shared codebase with gnap_make or we can integrate |
30 |
it in gnap_make directly. Since there will be large change in |
31 |
portage-2.2 GLSA abilities,we need to be more flexible. That's why I |
32 |
introduced thought of gnap_run, which will do what gnap_make do |
33 |
(including same params etc.) but can do whatever you want to do in |
34 |
chrooted environment of your embedded build. It could help us with |
35 |
debugging catalyst builds. Now we have to make all the "chroot work" |
36 |
done manually. It would look like gnap_run -t all "glsa-check -l" . I |
37 |
will also have to provide path to recent portage tree (we need recent |
38 |
glsa files) |
39 |
\ No newline at end of file |
40 |
-- |
41 |
gnap-dev@l.g.o mailing list |