From owner-freebsd-arch@freebsd.org Tue Dec 12 12:53:05 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39AF8E97AF6 for ; Tue, 12 Dec 2017 12:53:05 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9E2D7B154; Tue, 12 Dec 2017 12:53:04 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from [10.0.0.64] (ip-414b102e.ct.fixed.ntplx.com [65.75.16.46]) (authenticated bits=0) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTPSA id vBCCqvH3020680 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Dec 2017 07:52:58 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Tue, 12 Dec 2017 07:52:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: RFC: Sendmail deprecation ? From: Daniel Eischen X-Mailer: iPhone Mail (15C114) In-Reply-To: Date: Tue, 12 Dec 2017 07:52:57 -0500 Cc: freebsd.arch@clogic.com.ua, "freebsd-arch@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4C07192B-7B02-4A39-BEE5-CF60C6B2A335@freebsd.org> References: <201712111451.vBBEpjIW081611@pdx.rh.CN85.dnsmgr.net> <20171211195938.dxfji2pf2sq63my7@chittenden.org> <87882E8D-4A55-4F72-A897-7FD0FCD28DDB@freebsd.org> To: cem@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 12:53:05 -0000 > On Dec 11, 2017, at 7:11 PM, Conrad Meyer wrote: >=20 >> On Mon, Dec 11, 2017 at 3:44 PM, Daniel Eischen wr= ote: >> I do tend to agree with rgrimes, when -base is pkg-ized, folks will have a= chance to 'pkg install' or 'pkg remove' sendmail or anything else regardles= s of whether it is in -base or -ports. >=20 > pkg-base is totally orthogonal to the selection of what components we > want to have in base. That's sort of my point, in reverse. Don't use "if you want softwareX, just= 'pkg install softwareX'" as a reason to remove softwareX from base. > Base is really about defaults, and "what makes > a FreeBSD system." There's no reason to block this change on pkgbase, > or vice versa. People can remove the sendmail component on their > system today, but it isn't the default. How do they remove sendmail once it's installed ('rm' is so quaint ;-))?. T= hey can't pkg remove it. And when upgrading from media again, it gets reins= talled? When base is pkg-ized, once it's pkg removed it is never reinstalle= d when upgrading. It is also easier to turn off the installation defaults w= ith pkg base, so that some software is never installed by default. Sure, wh= en building and installing world it, you have the WITHOUT knobs, but that do= esn't help other common installation methods. >> The question should be, where do we want to maintain it? (There's also t= he history that exists in base that gets disconnected when it's in ports.) >>=20 >> -base is a set of packages that we deem more important than ports. Does s= endmail, as it is exists and configured in -base, pass muster for being some= thing that we consider important enough to warrant being in base? I think t= his is more of the question to ask than "why can't they install it from port= s?" Consensus seems to indicate no, but that we need some mail delivery age= nt. >>=20 >> I also think it should be incumbent on whomever removes something from -b= ase to make a port of it. >=20 > I disagree with that idea in general. The burden lands on people who > actually want to maintain the component, which may or may not overlap > with the person removing it from base. Removing a component is not > volunteering to maintain a port of that component, and shouldn't be. > (Also, having people who are willing to maintain a component is not by > itself sufficient justification for a component to remain in base.) >=20 >> I don't think we should just throw it over the fence and expect the ports= team to do the work, unless they volunteer for it. >=20 > mail/sendmail has been available as a port since 2000. But that port reportedly doesn't have the FreeBSD configuration files that w= e have in base. You'd be pushing the burden of maintaining them onto the po= rts maintainer, making sure they work on all supported branches; they may no= t want that responsibility. -- DE=