On Sunday 27 November 2005 02:03, Ned Ludd wrote:
On Sat, 2005-11-26 at 13:15 +0900, Jason Stubbs wrote:
On Saturday 26 November 2005 02:05, Ned Ludd wrote:
On Sat, 2005-11-26 at 00:51 +0900, Jason Stubbs wrote:
On Saturday 26 November 2005 00:31, Ned Ludd wrote:
* post_sync action hook (.53/.54 )
* VDB prevention of single byte NULL entries being created. ( .54 )
Doable for .54.
Yeah and from the sounds of it we may want more than 1 set of postsync
hooks or the addition of a postsync.d/
(dev thread on getting vital info to users)
Heh.. that was my suggestion. ;)
Yeah it seems doable for .53 but if you want to wait till .54 or
a .53-rXX thats fine. I'd prefer to see it in .53 unless
that's going out the door today.
2.0.53 is pretty much closed. After it hits 2.0.53, the only -r releases will
be for major regressions and security fixes. The only reason I think killing
of CDEPEND for 2.0.53 is okay is because nothing uses CDEPEND (I killed off
emerge scanning it already) so there's nothing to regress.
Should generating internal
debug info still be offered?
When FEATURES=nostrip is enabled we should not split off
any debug info or touch the executable.
FEATURES=splitdebug|stripdebug and do nothing if neither is set?
If feature based it seems logical to me to have it as either
splitdebug || nosplitdebug
That would be splitdebug or -splitdebug. I was suggesting stripdebug as a
replacement for -nostrip to get rid of another no* option and so that portage
could still be configured to give the current behaviour. As far as I can
tell, there are three possibilities:
* Do nothing
* Split of the debug info
* Strip any debug info
Have I got that right?
I know some people hate no* functions or rather they hate no* USE
flags. But it would seem fitting if we decided to make it a default vs
sticking in splitdebug in all profiles.
There's no need to touch the profiles. /etc/make.globals defines portage
defaults and is controlled by portage.
* flattened vdb {P,R,}DEPEND (.54 )
I might be wrong but I can't really see this being done cleanly. At
best, only USE flags could be gotten rid of which would still leave
|| () constructs. This leads me to question of what use it would
really be. If it can only do a half-arsed job and in a messy way at
that I'd personally prefer it to be done later on.
It will indeed still leave you with || ( foo bar ) or =cpv which you
can be parsed just fine. Yeah it would be nice if it could be reduced
more but later on or now I don't see how it can be reduced anymore than
to the requirements that the ebuild requested.
Again, if it can be done cleanly code-wise no issues with resolving the
USE flags out.
Should only be a few lines of code. (I hope)
Something like hand off the env varable from dyn_compile() in ebuild.sh
to python and python passes it back to ebuild.sh in the next phase for
dyn_install() which gets recorded flattened
There's no passing back of variables at the moment except through temporary
files. Perhaps USE and *DEPEND could be read in and *DEPEND rewritten out
after dyn_compile() completes?
--
Jason Stubbs
--
gentoo-portage-dev@gentoo.org mailing list
