1 |
On Sunday 27 November 2005 02:03, Ned Ludd wrote: |
2 |
> On Sat, 2005-11-26 at 13:15 +0900, Jason Stubbs wrote: |
3 |
> > On Saturday 26 November 2005 02:05, Ned Ludd wrote: |
4 |
> > > On Sat, 2005-11-26 at 00:51 +0900, Jason Stubbs wrote: |
5 |
> > > > On Saturday 26 November 2005 00:31, Ned Ludd wrote: |
6 |
> > > > > * post_sync action hook (.53/.54 ) |
7 |
> > > > > * VDB prevention of single byte NULL entries being created. ( .54 ) |
8 |
> > > > |
9 |
> > > > Doable for .54. |
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 |
2.0.53 is pretty much closed. After it hits 2.0.53, the only -r releases will |
24 |
be for major regressions and security fixes. The only reason I think killing |
25 |
of CDEPEND for 2.0.53 is okay is because nothing uses CDEPEND (I killed off |
26 |
emerge scanning it already) so there's nothing to regress. |
27 |
|
28 |
> > > > Should generating internal |
29 |
> > > > debug info still be offered? |
30 |
> > > |
31 |
> > > When FEATURES=nostrip is enabled we should not split off |
32 |
> > > any debug info or touch the executable. |
33 |
> > |
34 |
> > FEATURES="splitdebug|stripdebug" and do nothing if neither is set? |
35 |
> |
36 |
> If feature based it seems logical to me to have it as either |
37 |
> splitdebug || nosplitdebug |
38 |
|
39 |
That would be splitdebug or -splitdebug. I was suggesting stripdebug as a |
40 |
replacement for -nostrip to get rid of another no* option and so that portage |
41 |
could still be configured to give the current behaviour. As far as I can |
42 |
tell, there are three possibilities: |
43 |
|
44 |
* Do nothing |
45 |
* Split of the debug info |
46 |
* Strip any debug info |
47 |
|
48 |
Have I got that right? |
49 |
|
50 |
> I know some people hate no* functions or rather they hate no* USE |
51 |
> flags. But it would seem fitting if we decided to make it a default vs |
52 |
> sticking in splitdebug in all profiles. |
53 |
|
54 |
There's no need to touch the profiles. /etc/make.globals defines portage |
55 |
defaults and is controlled by portage. |
56 |
|
57 |
> > > > > * flattened vdb {P,R,}DEPEND (.54 ) |
58 |
> > > > |
59 |
> > > > I might be wrong but I can't really see this being done cleanly. At |
60 |
> > > > best, only USE flags could be gotten rid of which would still leave |
61 |
> > > > || () constructs. This leads me to question of what use it would |
62 |
> > > > really be. If it can only do a half-arsed job and in a messy way at |
63 |
> > > > that I'd personally prefer it to be done later on. |
64 |
> > > |
65 |
> > > It will indeed still leave you with || ( foo bar ) or >=cpv which you |
66 |
> > > can be parsed just fine. Yeah it would be nice if it could be reduced |
67 |
> > > more but later on or now I don't see how it can be reduced anymore than |
68 |
> > > to the requirements that the ebuild requested. |
69 |
> > |
70 |
> > Again, if it can be done cleanly code-wise no issues with resolving the |
71 |
> > USE flags out. |
72 |
> |
73 |
> Should only be a few lines of code. (I hope) |
74 |
> Something like hand off the env varable from dyn_compile() in ebuild.sh |
75 |
> to python and python passes it back to ebuild.sh in the next phase for |
76 |
> dyn_install() which gets recorded flattened |
77 |
|
78 |
There's no passing back of variables at the moment except through temporary |
79 |
files. Perhaps USE and *DEPEND could be read in and *DEPEND rewritten out |
80 |
after dyn_compile() completes? |
81 |
|
82 |
-- |
83 |
Jason Stubbs |
84 |
-- |
85 |
gentoo-portage-dev@g.o mailing list |