From owner-freebsd-ports@FreeBSD.ORG Thu May 4 14:12:20 2006 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B71A16A402 for ; Thu, 4 May 2006 14:12:20 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DAC643D5A for ; Thu, 4 May 2006 14:12:04 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id o25so349124nfa for ; Thu, 04 May 2006 07:12:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=pYmCMhw+iU5CTAs32r9kQYk00Fafj031EVp011Y/JzzIyIw6V+Xd3ifarjqwFKU+v1z/HrxelzPiMWMxgut9BgyHlsSdmg5jHktUPM8qZ3F5dZklAGrtWR4w1Y9yevMschVZSuHPAAWDzfGzN+IuXNclkaNIewq73RLQVTryCBM= Received: by 10.48.229.4 with SMTP id b4mr199765nfh; Thu, 04 May 2006 04:15:22 -0700 (PDT) Received: from roadrunner.q.local ( [217.185.119.254]) by mx.gmail.com with ESMTP id m15sm4626615nfc.2006.05.04.04.15.20; Thu, 04 May 2006 04:15:22 -0700 (PDT) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.6/8.13.6) with ESMTP id k44BEpJO003036 for ; Thu, 4 May 2006 13:14:52 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.6/8.13.6/Submit) id k449ftnO002639 for freebsd-ports@freebsd.org; Thu, 4 May 2006 11:41:55 +0200 (CEST) (envelope-from uspoerlein@gmail.com) Date: Thu, 4 May 2006 11:41:55 +0200 From: Ulrich Spoerlein To: freebsd-ports@freebsd.org Message-ID: <20060504094155.GC984@roadrunner.q.local> Mail-Followup-To: freebsd-ports@freebsd.org References: <44538D42.8030301@chrismaness.com> <200605010901.50654.aren.tyr@gawab.com> <20060501091523.GA38820@pentarou.parodius.com> <200605021827.34873.aren.tyr@gawab.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5G06lTa6Jq83wMTw" Content-Disposition: inline In-Reply-To: <200605021827.34873.aren.tyr@gawab.com> Subject: Re: Upgrade Tool 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: Thu, 04 May 2006 14:12:20 -0000 --5G06lTa6Jq83wMTw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Aren Olvalde Tyr wrote: > Perhaps it would be good, if, say on the corresponding port entry on the= =20 > FreeBSD ports webpage, it listed all the options used for building the bi= nary=20 > package. For example, for the "Package" link, instead of simply linking t= o=20 > the package, it could link to a page entry listing all of the build optio= ns=20 > used, with the package download link at the bottom. Or something like tha= t.=20 >=20 > Just an idea. What do people think?=20 I'd even go further. This is something I have been thinking about on and off. Namely, a FLAVOUR system for packages. A maintainer specifies up to three FLAVOURs per port, which set various flags for building the port. These might be full|normal|minimal or mysql|pgsql, etc. The package build cluster will then produce a package for each flavour. The problem is to integrate this with the pkg_* tools. Should the packages be called foo-1.2.3_1-minimal.tbz2? Which version do you get if you pkg_add -r foo? etc. This is where I don't see a clever way of integration. If, and only if, the flavours only differ in some files of their plists (the binaries and lib, perhaps) it might even be beneficial to lump all different flavours into one package. Sure, the bin and libs then take up three times the space, but all stuff in share is only required once. A clever pkg_add can then look up which flavours are inside a package, and which flavours have all their dependencies satisfied, if there are conflicts, etc. I'm just dreaming here ... What sparked this idea, is that there is no mplayer package (at least, I didn't find one). This is probably, because it depends on some codecs, which can be redistributed. The idea now is to leave the port as it is, so people can still 'make install' it like before. But the package build cluster will produce a mplayer FLAVOUR called 'unrestricted' which will depend solely on, well, unrestricted packages. Thus, we get a redistributeable mplayer package. Yay! The maintainer might even specify unrestricted|minimal|full flavours, so people don't need to set dozens of WITH_FOO=3Dyes, but can simple run 'make WITH_FLAVOUR=3Dfull install'. Ulrich Spoerlein PS: I used the mplayer port/package purely for demonstrative purposes! --=20 PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. --5G06lTa6Jq83wMTw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEWcxj524iJyD+6d0RAtSOAJ9X1RZCJH4J9j84MYJxJOJsrlK1qgCfc2nW 2ZRjRnvshwugtWXRgbR652s= =tACI -----END PGP SIGNATURE----- --5G06lTa6Jq83wMTw--