portage 2.1.2_pre2 and pre2-r1: There's a discrepancy between the discussion on bug #148870 and the emerge manpage (as referenced in the ewarn). portage behaves as on the bug, so the manpage is incorrect. current manpage: --with-bdeps < y | n > Where's the required equals? That takes care of the immediate issue. However, there's another more subjective one as well, that I noticed when I was setting up my defaults (--with-bdeps=y). Setting it up that way just "feels wrong" in terms of the way portage normally works. What would have "felt right" would have been having this as a feature, but keep the --with-bdeps command line override if desired. Set up FEATURES=without-bdeps and/or FEATURES=with-bdeps, with the default if neither one is given being the present n for install, y for depclean. Again, keep the command line switch for overriding the feature. With EMERGE_DEFAULT_OPTS, the present system works, but it just doesn't seem very "portage-like", and will likely be unintuitive and therefore problematic (read more unnecessary bugs raised) once it hits stable. Just my opinion there, but that's what I think, unless the object is to deprecate features and eventually move them all to command line options, with defaults to be but in EMERGE_DEFAULT_OPTS, because that's where the logic would seem to lead if extended. Nothing wrong with that if so; it just doesn't have the traditional portage way of doing things feel to it, and is likely to mix folks up as a result, so I'd suggest we have a good reason if we are going to keep it as it is now. Duncan
(In reply to comment #0) > current manpage: > --with-bdeps < y | n > Actually, it works either way. We're using python's optparse module and it accepts either --with-bdeps=y or --with-bdeps y style syntax. Quite nice, isn't it? > Set up FEATURES=without-bdeps and/or FEATURES=with-bdeps I'm reluctant to add an emerge specific option to FEATURES. It doesn't affect any part of portage beyond emerge, so I don't see a compelling reason to stick it in FEATURES (FEATURES is really quite bloated as it is). I'd prefer to reserve FEATURES for options that truely need to be "global".
(In reply to comment #1) > (In reply to comment #0) > > current manpage: > > --with-bdeps < y | n > > > Actually, it works either way. We're using python's optparse module and it > accepts either --with-bdeps=y or --with-bdeps y style syntax. Quite nice, > isn't it? Oops. Typo on my part. I had EMERGE_DEFAULT_OPTS-"--with-bdeps y" and got the following error, only I misinterpreted the "=" reference, and with -"--with-bdeps=y" I no longer got the error, tho it was still incorrect as it had a dash in place of the equals after EMERGE_DEFAULT_OPTS. Since putting =y eliminated the error, I thought sure that was the problem. =8^( !!! Invalid token (not "=") y" !!! "ParseError: Invalid token (not '='): /etc/make.conf: line 21 in /etc/make.conf" !!! Incorrect multiline literals can cause this. Do not use them. I still think it belongs in features, but see your point on that, and since the above was PEBKAC, closing as such. Sorry, but thanks for the help and quick turnaround. Duncan
