From owner-freebsd-ports@FreeBSD.ORG Sat Apr 5 19:34:09 2008 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F42C106566B for ; Sat, 5 Apr 2008 19:34:09 +0000 (UTC) (envelope-from mkhitrov@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id E65D58FC1A for ; Sat, 5 Apr 2008 19:34:08 +0000 (UTC) (envelope-from mkhitrov@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so117479ywt.13 for ; Sat, 05 Apr 2008 12:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OGnMs0HlQOZX4lWx4Oe/cYdYTZtuPLc0wR6wXOeMyi0=; b=c4V6mjDX2QexurI6jaPa7WdJ61PizqAZDyLDWbJDnQVA8PyaItd4E993OVA0JPH0xEZ/oyRK5OsGo3dQcEstNJle1jgxc5Af0PWUT5rKWMGSqTHy6tdxwCN2dRdVTzJyybxR+0nSEI9lT8KHYVETdo65JCrlzhmiZIH6tsawi30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ua4XGfnkr/OkQ6YtO1Yx2nLmqABaaZ9wC/EwcfyaSe66cVGXa7WjcdMehdRKZ5GWVBKZ0wlPBPLOsOGGrqYnQqqu2iNSDaWLfrgKw0FUb9RjtrrYz0XnTARQD51CR4uAuXM98oDKopIshqwg2nn++qae9J51x9uwRqpQE4dcSb8= Received: by 10.150.145.14 with SMTP id s14mr1505256ybd.154.1207424048283; Sat, 05 Apr 2008 12:34:08 -0700 (PDT) Received: by 10.150.146.6 with HTTP; Sat, 5 Apr 2008 12:34:08 -0700 (PDT) Message-ID: <26ddd1750804051234s67ba8b70l1276fe964e34ab62@mail.gmail.com> Date: Sat, 5 Apr 2008 15:34:08 -0400 From: "Maxim Khitrov" To: "Philip M. Gollucci" In-Reply-To: <47F7CBBD.4050107@p6m7g8.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <26ddd1750804041811p4bb2c4f5tbab3f9659f88e8bb@mail.gmail.com> <47F7CBBD.4050107@p6m7g8.com> Cc: freebsd-ports@freebsd.org Subject: Re: FreeBSD Custom Package Server X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2008 19:34:09 -0000 On Sat, Apr 5, 2008 at 2:58 PM, Philip M. Gollucci wrote: > Maxim Khitrov wrote: > > > First question I have is if anyone is aware of software that already > > does this sort of thing? How well does it work? If not, I plan try to > > write this on my own. > > > > You can maintain 1 host with multiple jail(8)s. Each will have a custom > /etc/make.conf. You can even different architectures for in different > jails. > In my experience, you should have 1 jail for each different software stack > (aka set of packages). In large production environments, its very typical > to have 'classes' of machines. AKA proxy machines, app machines, database > machines..... Each set would have a different set of packages. That's something that I'd like to avoid - having a separate environment for each unique server configuration. The advantage that you get in large production environments is not realized for regular home users like myself, who don't have any two servers that are similar. In addition to that, this method will take up way too much disk space. I can understand having separate package servers for FreeBSD 6 and FreeBSD 7 clients, but that's where I'd like the limit to be. If I have to maintain a mirror for every server, then yes, it would allow me to offload the package-building, but at a much higher overall maintenance cost. I currently have three FreeBSD 7 machines at home and I want all of them to share a common build server with at most one jail if that server is used for other things. A request for new package should contain in itself all the relevant settings. If that means sending the make.conf file from the client to the server - fine. Have the build server adapt for each new request, build the requested port and dependencies, create the package(s), and remove the port from the local system. The client can then download the package, build server goes on to process the next request, and no disk space is wasted. Am I being a bit overambitious? :) - Max