From owner-freebsd-current@FreeBSD.ORG Tue May 10 19:35:41 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9132B16A4CE for ; Tue, 10 May 2005 19:35:41 +0000 (GMT) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1A9243D75 for ; Tue, 10 May 2005 19:35:40 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j4AJZc9n022093 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 11 May 2005 05:35:39 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j4AJZZGK000285; Wed, 11 May 2005 05:35:38 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j4AJZZh7000284; Wed, 11 May 2005 05:35:35 +1000 (EST) (envelope-from pjeremy) Date: Wed, 11 May 2005 05:35:35 +1000 From: Peter Jeremy To: Brian Candler Message-ID: <20050510193535.GA214@cirb503493.alcatel.com.au> References: <20050509114410.GA2184@uk.tiscali.com> <20050510.005542.95903608.imp@bsdimp.com> <20050510111423.GA7955@uk.tiscali.com> <1115735657.20796.15.camel@tomcat.kitchenlab.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1115735657.20796.15.camel@tomcat.kitchenlab.org> User-Agent: Mutt/1.4.2i cc: freebsd-current@freebsd.org Subject: Re: Packaging of base system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2005 19:35:41 -0000 Overall, I think that packaging the base system is a good idea for end-users. In theory, it means that upgrades can be handled by a wrapper around portupgrade and the pkg_* tools can be used to verify system consistency. OTOH, I'm not sure that it is of much benefit to developers - unless you replace "make world" with portupgrade, the base system package information will be out-of-date following the first installworld. It might be useful asking for opinions in some of the "end user" lists as well as here. On Tue, 2005-May-10 07:34:16 -0700, Bruce A. Mah wrote: >Honestly I'm not sure if I like this idea or not. My most recent >experience with a fully packaged system is with RH/FC Linux >distributions and many times I feel like I'm in a twisty little maze of >RPMs, all different. You seem to be proposing a more coarse-grained >packaging, which I think is more workable. OTOH, Solaris and Tru64 are fully packaged and this seems to work - though both are (probably too) fine grained. I suspect that fine grained makes the dependencies easier to manage, but in the case of both Solaris and Tru64, working out whether you want a particular package or not is virtually impossible. If you do go the fine-grained approach, it may be worthwhile having a group of "dependency" packages that are gathered in a section headed "you probably don't want to individually select these packages - they will be installed automatically if required". I suspect the only serious problems will be: - adapting the source build/install environment to update the relevant package info (if you even attempt this); - handling installing "base" packages that are required by a port[*] - avoiding circular dependencies; - handling the bikeshed on which utility goes in which package. As my input on the last item, I'd suggest that "client" and "server" tools should be in separate packages: I think that lots more people will be interested in ftp and telnet than want ftpd or telnetd. And whilst few people want named, almost everyone wants the client resolver libraries (which together form "bind"). [*] This is especially messy if you use fine-grained packaging (so that some of the less common libraries might be missing) and the source upgrade path isn't integrated into the packaging. -- Peter Jeremy