From owner-freebsd-ports@FreeBSD.ORG Mon Feb 14 09:36:29 2005 Return-Path: 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 7A20616A4CF; Mon, 14 Feb 2005 09:36:29 +0000 (GMT) Received: from fly.ebs.gr (fly.ebs.gr [62.103.84.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A29543D31; Mon, 14 Feb 2005 09:36:28 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id j1E9aQBu066372; Mon, 14 Feb 2005 11:36:26 +0200 (EET) (envelope-from past@ebs.gr) Received: from [10.1.1.200] (pptp.ebs.gr [10.1.1.200]) by ebs.gr (8.12.11/8.12.11) with ESMTP id j1E9aGCU043968; Mon, 14 Feb 2005 11:36:18 +0200 (EET) (envelope-from past@ebs.gr) Received: from 127.0.0.1 (AVG SMTP 7.0.300 [265.8.7]); Mon, 14 Feb 2005 11:36:09 +0200 Message-ID: <42107108.5000901@ebs.gr> Date: Mon, 14 Feb 2005 11:36:08 +0200 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Palle Girgensohn References: <42106C38.6060006@ebs.gr> <408B661F5EDB9C3D9623E3E5@rambutan.pingpong.net> In-Reply-To: <408B661F5EDB9C3D9623E3E5@rambutan.pingpong.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: ports@freebsd.org cc: java@freebsd.org Subject: Re: postgresql-jdbc packaging X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 09:36:29 -0000 Palle Girgensohn wrote: > > > --On måndag, februari 14, 2005 11.15.36 +0200 Panagiotis Astithas > wrote: > >> Palle Girgensohn wrote: >> >>> Hi! >>> >>> I'm maintaining the postgresql-jdbc port. >>> >>> One thing I've considered, but not come to any conclusion about, is >>> whether the port should register somehow which version of JDBC it has >>> built, JDBC1, JDBC2 or JDBC3. There's even a JDBC2 + EE variant... Which >>> version is built depends on which JDK was used to build it. jdk1.1 => >>> JDBC1, jdk1.2-1.3 => JDBC2, and jdk1.4+ => JDBC3. Hence, very few would >>> want JDBC1 nowadays, I suppose. The only package built by the package >>> cluster now is for JDBC1, which kind of sucks a bit :) >>> >>> To fix this, the right way is to create a bunch of slave ports, on for >>> each type as per above. Then, the package building cluster would build >>> all version. The slave ports would set JAVA_VERSION=1.1 and 1.2 >>> respectively, and the main port could install the greatest version. >>> PKGNAMESUFFIX would be set to jdbcN. >>> >>> Is this just overkill? If most of you use the port anyway, it probably >>> is, but if ppl tend to use prebuilt packages, they will end up with a >>> somewhat crippled JDBC1 jar even if they run jdk-1.5, so then it might >>> be worth it. >>> >>> I slimmer way is to just let the package name reflect which version has >>> been built, but not bother to create slave ports. >>> >>> Any opinions? What do you think, is it worth the effort? >>> >>> /Palle >>> >>> (See for info on different >>> versions of PostgreSQL's JDBC.) >> >> >> As someone who was bitten by this, I believe package users should have >> some sort of warning sign. I don't mind what the solution will be, as >> long as a regular "pkg_add -r foo" can work as expected. Is this possible >> with the "slimmer" approach? >> >> Cheers, >> >> Panagiotis > > > With the slimmer approach, pkg_add will install postgresql-jdbc1, > explicitally. With the fatter approach, there will be three packages to > chose from, one each for jdbc{1,2,3}. > > /Palle > So, in the former case, one would not be able to install a package other than -jdbc1, even if native binary jdk versions exist for 1.3, etc.? If I understand it correctly we are currently not building postgresql-jdbc2, even though we have a binary jdk 1.3, right? This sounds rather limiting. Can't the package cluster build at least postgresql-jdbc2, too? And when we get binary distributions for jdk 1.4/1.5, build packages for postgresql-jdbc3? If this requires the "fat" approach, then I'm all for it. Cheers, Panagiotis