On Sun, 9 Apr 2017 22:04:13 -0400 "William L. Thomson Jr." <wlt...@o-sinc.com> wrote:
> This has never been the case with Java. Its not a problem with C binaries either, because you have a discrete compile time, and language level interop between compiled binary forms. Meanwhile, you cannot build two parts of a given python dependency chain with different pythons, nor different perls. > If package A requires version X, but B Y, then B builds with Y as its > pulled in as a dep. while A proceeds to build with X. > > Where this is different for Python, Ruby, and also Perl. They all > install files into a directory based on version. You may have multiple > copies in each, vs one. Perl does not have targets, nor does Java. Right, but this is impossible with Ruby, Python, and Perl. Perl *could* have targets, and some people think could do with it, but it and java are very much in different boats. Perl is in the same boat as Python and Ruby where in "new version of thing" means "everything must be compiled with the new target" Perl simply has a *moving* target instead of multiple concurrent targets. Essentially, with Perl we've done the effect of "Add X, Remove Y" for all things. We additionally have a much better precedent than python at syntax-interop between versions, so its more justifiable to only have the single target ( because you practically never need an older perl "just for compat reasons", though at the rate this garbage[1] is going, that could change one day ) If anything, Perl is only avoiding the Python problem you hate with significant amounts of heroism, and its only a matter of time before upstream force our hands in ways that make that heroism non-viable, and we have to dig deep and work out how the hell to maintain concurrent targets. > The present system is a PITA for users. Fiddling with adding/removing > targets for Python/Ruby. In addition to selecting which for the system. > All these same problems exist for Java, with the exception of > installation locations as mentioned. I honestly think you're looking at the wrong problem domain to fix this problem, in ways that will introduce yet more regressions and broken trees. We should have what I've been saying we should have for a while now: * Soft Options. We only have 2 types of option at present from the users perspective, "on" options, and "off" options. Portage doesn't even distinguish between who is setting them, user profile and the gentoo profiles simply flatten into a single logical profile, and then portage then demands that changes be made to this set, failing to discriminate at all between "ok, this was the profile specified default and it needs to be non-default for this problem" and "user doesn't actually want this, how can we avoid that" And portage then compounds this by dictating that any option changes that ebuilds need must be enshrined by the user as things the /user/ wants, when in truth, they're not things the user wants, they're things the ebuilds want, and the user begrudingly accepts. Hence why an option of "on, but only if portage really needs it" is missing, but needed. I would gladly set soft-targets of every python version under the sun, and then allow portage to turn them on *as necessary*, and this would be much preferable to having to either a) turn them on globally and pull in stuff and waste time compiling stuff that's not even getting used. b) Maintain a painful and carefully catered list of things to prevent aforementioned problems. In short, users need a way to discriminate "things I care about" from "things I don't care about" Currently, its just a big cluster of those things in one place, and the complexity is inescapably thrust into the users hands on a daily basis. 1: https://bugs.gentoo.org/showdependencytree.cgi?id=613764&hide_resolved=0
pgpF4zTjVMYjD.pgp
Description: OpenPGP digital signature
