Date: Tue, 03 Dec 2013 18:11:00 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: freebsd-stable@freebsd.org Subject: Re: BIND segway -> python -> first-class ports Message-ID: <529E8F34.5040604@freebsd.org> In-Reply-To: <529E8C53.6020208@freebsd.org> References: <mailman.313.1386119137.1390.freebsd-stable@freebsd.org> <529E8C53.6020208@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/3/13, 5:58 PM, Julian Elischer wrote: > On 12/4/13, 9:05 AM, Mark Felder said: > ----------------- > >> There was no alternative; we couldn't keep BIND in base. BIND 9 will >> certainly have a EoL before the EoL of FreeBSD 10.x, and we can't use >> BIND 10 because it requires importing Python to base. > > I'm coming more and more to the conclusion that we should have a > minimal Python in "base". > More and more people are expecting it and more and more software needs > it. > > But maybe the problem is our definition of "base". > > I have said before that in my opinion we should have two classes of > ports. > Mechanically they are handled the same but class 1 ports are "standard > additions", > and if they don't work it's a "stop-ship" condition.. These would be > MAJOR ports.. > like a minimal python, a minimal Perl (ok yuk but some people would > insist), > BIND, Sendmail, bash, and other things that people EXPECT to be in a > FreeBSD system. > If you break such a port it has the same weight as breaking something > in base, > but it's not base.. I think you would agree that while it would be a major boost in productivity for us to have python in base, at the same time it would cause quite a bit of problems as "FreeBSD's" python would be out of date or it would give the appearance that we only support a single version of python (unless we kept it bleeding edge). A workaround for this problem is to bring in python, but to hide it under /usr/bsd/bin and only allow system utilities to explicitly reference it. In fact a number of our other tools should very likely go under there or some mechanism such as the "use.perl" tool needs to be made not only for python, but also for clang and gcc. Why? Well because the outsiders I've talked to run FreeBSD and see older versions of the utilities in base (even though newer versions exist in ports) and wind up assuming that's the newest version that can work on FreeBSD and ignore ports. After a while those users run away to Linux where you just "apt-get cc" and get the shinest newest thing possible on any distro you consider relevant today. We MUST decouple the base requirements from what users want from ports. *WE* might want python 2.x OR *we* may want 3.x, but by putting it under /usr/bin and polluting the user's environment we lock the user into it. We must not do that otherwise we repeat the tcl fiasco and the perl fiasco and the gcc/egcs/clang fiasco over and over and over again. So yes, let's get python in base, but *not make it user visible*. We need to only make it visible for internal use of our "src base". The point being we need to keep ports/packages as the defacto place where people get python from, while the base system itself has its own version it uses. Either that or we need to throw in the towel and go into more of a distro model where things like python and bind are never part of /usr/src, however they are by default installed. Or, finally the choice can always be put the onus onto the user to install such packages OR leave it to the distro maintainer, an example being PC-BSD, or JulianBSD. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?529E8F34.5040604>