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
