On 03/05/2017 11:44 AM, Michael Orlitzky wrote: > On 03/05/2017 02:12 PM, Zac Medico wrote: >> >> Incorrect. >> >> ... >> >> Incorrect. >> > > I see my mistakes, but maintain that this is confusing =)
It could be worse, and I think it's questionable that we could do any better, given the nature of the problem. >> The --with-bdeps-auto option results in desirable behavior by default, >> and it's also backward compatible with existing --with-bdeps and >> --usepkg usage. It just does the right thing, minimizing the impact to >> existing emerge usage. > > I was hoping that since nothing breaks with --update-bdeps=y and > --clean-bdeps=n (the new defaults), we could just disable --with-bdeps > immediately and emit a warning when it's given. Breaking backward compatibility is too disruptive, unless we allow for a transition period where --with-bdeps is deprecated. >> There some problems with --update-bdeps/--clean-bdeps: >> >> * The program logic will be more complicated, since --with-bdeps will >> have to override both options for backward-compatibility with existing >> --with-bdeps usage. > > Not applicable if --with-bdeps goes away. We don't have a justification to break compatibility without a transition period. >> * The meaning of --clean-bdeps is confusing. Does --clean-bdeps=y mean >> to clean build time deps, or does it mean to pull build time deps into >> the dependency graph for removal operations? > > --clean-bdeps means clean the bdeps. It's confusing to have an option with inverted meaning relative to --with-bdeps. Cleaning the bdeps is a consequence of excluding them from the dependency graph, not an action in itself. --clean-bdeps sounds like an action. > I totally agree that the worst option of all is to keep --with-bdeps AND > introduce the other two. -- Thanks, Zac
