1 |
On Sat, 2005-11-26 at 13:15 +0900, Jason Stubbs wrote: |
2 |
> On Saturday 26 November 2005 02:05, Ned Ludd wrote: |
3 |
> > On Sat, 2005-11-26 at 00:51 +0900, Jason Stubbs wrote: |
4 |
> > > On Saturday 26 November 2005 00:31, Ned Ludd wrote: |
5 |
> > > > * post_sync action hook (.53/.54 ) |
6 |
> > > > * VDB prevention of single byte NULL entries being created. ( .54 ) |
7 |
> > > |
8 |
> > > Doable for .54. |
9 |
|
10 |
.... |
11 |
|
12 |
|
13 |
> > Yeah and from the sounds of it we may want more than 1 set of postsync |
14 |
> > hooks or the addition of a postsync.d/ |
15 |
> > (dev thread on getting vital info to users) |
16 |
> |
17 |
> Heh.. that was my suggestion. ;) |
18 |
|
19 |
Yeah it seems doable for .53 but if you want to wait till .54 or |
20 |
a .53-rXX thats fine. I'd prefer to see it in .53 unless |
21 |
that's going out the door today. |
22 |
|
23 |
> > > > * new prepstrip offering splitdebug ( .53/.54 ) |
24 |
> > > |
25 |
> > > Need to work out exactly what will be offered when on this one, but at |
26 |
> > > the earliest it will be .54. Perhaps go with your patch for .54 and leave |
27 |
> > > Olivier's fancy bits for later? |
28 |
> > |
29 |
> > I can only assure you the code I wrote will function properly. |
30 |
> > So that's the only thing I'm trying/willing to push myself. |
31 |
> > As long as he has those [ -x checks ] his code should be harmless, |
32 |
> > but I don't see the advantage in it over building with -g3. |
33 |
> > |
34 |
> > > There are a few other questions too... Should |
35 |
> > > the default be to generate external debug info? |
36 |
> > |
37 |
> > I think the security team would say yes they want it by default and |
38 |
> > would be willing (taviso) to write a proper debug-HOWTO.xml for gentoo. |
39 |
> > I think ferringb would say make it FEATURES=splitdebug if |
40 |
> > it's going in midstream. |
41 |
> > |
42 |
> > It does add some size which would make peoples $ROOT's a little bit |
43 |
> > bigger. But from mine and other peoples testing it's pretty damn |
44 |
> > minimal. I think Halcy0n @ gentoo said after doing an -e world he ended |
45 |
> > up with only 18M of split debug info |
46 |
> > |
47 |
> > I'm also fond of split packaging of debug info also (but I'm not going |
48 |
> > to push for that till I find a more elegant way) |
49 |
> > |
50 |
> > solar@simple debug $ qsize pax-utils |
51 |
> > app-misc/pax-utils-debug-0.1.4-r0: 3 files, 5 non-files, 16.27 KB |
52 |
> > app-misc/pax-utils-0.1.4: 6 files, 6 non-files, 102.485 KB |
53 |
> > |
54 |
> > Perhaps we should get input from gentoo-dev ml ? |
55 |
> |
56 |
> Sounds good for pretty much all aspects of split debug (other than the |
57 |
> capability itself). |
58 |
> |
59 |
> > > Should generating internal |
60 |
> > > debug info still be offered? |
61 |
> > |
62 |
> > When FEATURES=nostrip is enabled we should not split off |
63 |
> > any debug info or touch the executable. |
64 |
> |
65 |
> FEATURES="splitdebug|stripdebug" and do nothing if neither is set? |
66 |
|
67 |
If feature based it seems logical to me to have it as either |
68 |
splitdebug || nosplitdebug |
69 |
|
70 |
I know some people hate no* functions or rather they hate no* USE |
71 |
flags. But it would seem fitting if we decided to make it a default vs |
72 |
sticking in splitdebug in all profiles. |
73 |
|
74 |
The feeling I get in general is that some devs want it by default to |
75 |
make helping users who don't really know how to debug give us the info |
76 |
we need without much hassles. |
77 |
|
78 |
stripdebug I'm not sure what you envision with that name. |
79 |
|
80 |
|
81 |
|
82 |
> > > > * flattened vdb {P,R,}DEPEND (.54 ) |
83 |
> > > |
84 |
> > > I might be wrong but I can't really see this being done cleanly. At best, |
85 |
> > > only USE flags could be gotten rid of which would still leave || () |
86 |
> > > constructs. This leads me to question of what use it would really be. If |
87 |
> > > it can only do a half-arsed job and in a messy way at that I'd personally |
88 |
> > > prefer it to be done later on. |
89 |
> > |
90 |
> > It will indeed still leave you with || ( foo bar ) or >=cpv which you |
91 |
> > can be parsed just fine. Yeah it would be nice if it could be reduced |
92 |
> > more but later on or now I don't see how it can be reduced anymore than |
93 |
> > to the requirements that the ebuild requested. |
94 |
> |
95 |
> Again, if it can be done cleanly code-wise no issues with resolving the USE |
96 |
> flags out. |
97 |
|
98 |
Should only be a few lines of code. (I hope) |
99 |
Something like hand off the env varable from dyn_compile() in ebuild.sh |
100 |
to python and python passes it back to ebuild.sh in the next phase for |
101 |
dyn_install() which gets recorded flattened |
102 |
|
103 |
If it's not doable then I'll just go for a simple cosmetic patch to |
104 |
remove newlines and extra spaces. |
105 |
|
106 |
-- |
107 |
Ned Ludd <solar@g.o> |
108 |
Gentoo Linux |
109 |
|
110 |
-- |
111 |
gentoo-portage-dev@g.o mailing list |