postgresql-jdbc packaging

[Panagiotis Astithas]

Palle Girgensohn wrote:
> 
> 
> --On måndag, februari 14, 2005 11.15.36 +0200 Panagiotis Astithas 
> <past at ebs.gr> 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 <http://jdbc.postgresql.org/download.html> 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