On Mon, May 17, 2021 at 12:28:24PM -0700, Mark Millard via freebsd-ports wrote: > bob prohaska fbsd at www.zefox.net wrote on > Mon May 17 15:55:21 UTC 2021 : > > > The existing conflict between versions of python strikes me as more of a > > planning problem than a software bug. It may be naive, but I don't see > > why python37 and python38 can't use distinct names for files placed in > > system directories. > > You seem to be under the impression that absent having > any common file paths, things would just work. This > seems unlikely. A simplified presentation of why > follows. >
I'm under the impression that absence of common paths would help reduce conflicts. In the case at hand it might be sufficient. > Imagine two programs: > > p37 that is set up for python37 > p38 that is set up for python38 > > imagine that both use a library plib that is > not internal to each but external to both. > > So should plib be built/present for python37? > python38? Both? > > If both: it suggests building a huge set of python > software multiple times, once per supported version > in the range of to-be-supported python versions. (I > do assume python versions make for some degree of > incompatibility distinctions. It might be only only > some version changes have that property. But such > would not change the basic point.) > It suggests that p37 (installed first) would install its preferred version of plib. When p38 is installed, it would test for a compatible version of plib and add a new one, with a different name, if the prior version isn't satisfactory. Libraries already seem to have a variety of suffixes on their names, so it appears something of the sort is already going on. Am I completely missing the point? > I know, for example, python39 invalidated code in > something I've built in a non-FreeBSD context. The > software had to be modified to be compatible with > both older python's and python39 (if they wanted > to support the older versions as well going > forward). (It was not a context of wanting to take > advantage of new things in the newer python. But > that kind of context is not universal.) Not sure I see a fundamental problem here. Python 38 remaining useful/necessary after introduction of 39 doesn't seem so bad. It seems the norm. > Most ports having a separate upstream to deal with > and having a huge number of ports makes for > port-developer and upstream-developer coordination > based solutions having great difficulties overall. > Indeed, and they're getting worse over time. > No technical-content has been presented to make these > sorts of problems disappear. With the problems being > present, it is a matter of working in a way that > avoids running into the problems or with dealing with > fixing things when the problems occur. I've wondered from time to time if it's possible, even only in principle, to make the entire ports tree build in one invocation. At the moment, the answer seems to be "no". But is it "no" on first principles? > I've done both > basic styles over the years and recognize tradeoffs. > I'm happy to help someone explore one of the ways > in which poudriere can be an alternative. It is not > for me to declare how well it would end up fitting > their goals, context, preferences, and so on vs. > other alternatives overall. > I'll continue to explore poudriere. Your efforts are much appreciated, but also rather daunting. The learning curve is steep and resource requirements are high. If there's some larger point I'm missing please give a hint. Thanks for writing! bob prohaska _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
