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..> Keep in mind that Unbound is not planned to be a permanent addition to > base either. It's merely a stop-gap until Capser is complete, which will > then provide the DNS services in base. >http://blog.des.no/2013/09/dns-again-a-clarification/That makes removing BIND even less sensible if you are forcing people to go through all this pain TWICE. We were promised in spirit if not words that the BIND port would be pretty much a drop-in replacement. but it appears that FreeBSD users are going to have to do quite a bit more work due to this dance. Will there be a Unbound port that is a drop-in replacement for in-base unbound?
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
On Wed, 4 Dec 2013, 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..+1. I am concerned by the tendency towards Nazism in base. I would like to see the usual suspects (BIND, sendmail) kept in base. If we have to import a minimal python (into some place that ports won't see it, as Alfred suggests), then so be it. Updating ports is mostly a crap-shoot. With FreeBSD 9.x-stable, I can build and install world and get a mostly complete system, with BIND, sendmail, NAT, IPFW, etc. If something breaks, I know that it'll be fixed pretty quick, and don't need to be so concerned. If a port breaks, yeah, sure, it might get fixed, but in the mean time hundreds of other ports have been updated and some other dependency might have broken something. It's sometimes like playing whack-a-mole. Things are getting better, with pkgng & poudriere, though there is not a -stable ports tree to match -stable src.>> Keep in mind that Unbound is not planned to be a permanent addition to >> base either. It's merely a stop-gap until Capser is complete, which will >> then provide the DNS services in base. >> http://blog.des.no/2013/09/dns-again-a-clarification/ > > That makes removing BIND even less sensible if you are > forcing people to go through all this pain TWICE. We were promised in spirit > if not words that the BIND port would be pretty much a drop-in replacement. > but it appears that FreeBSD users are going to have to do quite a bit more > work due to this dance. Will there be a Unbound port that is a drop-in > replacement for in-base unbound?+1 again. Why not keep BIND in, and move to Casper once it is complete? <back to lurking> -- DE
On Dec 3, 2013, at 6:58 PM, Julian Elischer <julian at freebsd.org> wrote:> 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..Whether we like it or not, 'pkg' is now (as of 10.0) effectively a "first-class" port, since although it lives in ports it is relied on by the base system (pkg bootstrapper) to provide core functionality (package management). Since we have such a distinction it would be useful to make official so we could, for example, do more frequent build and regression tests of such ports. And if we're going to do that for one port we might as well do it for several... JN