Ville Skyttä wrote:
IMO that would be too much dictating local policies from our part, and subject to inherent distributed bitrot because folks usually download jpackage.repo only once. And I'm sure this stuff would not be limited to postgresql-jdbc.
I don't understand your argument. Are you saying that the file can never be changed? Probably, it should be put into it's own package in the Fedora repos.
There's a larger question here. What is the "co-existence strategy" for JPackage and Fedora Core? I'm trying to figure out how to set up a Java development/Tomcat server environment on FC4, and I'm very unsure how to set things up so that yum doesn't eventually leave me with an incompatible mishmash of JPackage (Java) and Fedora (gcj) packages.
Maybe the FC postgresql-jdbc package could have a versioned Provides: using the full version number (including the build) of the drivers it contains, like the corresponding JPP one has in its version field? Would that work the way you'd expect? (What would you expect, BTW?)
Getting the Fedora postgresql-jdbc package to somehow reflect the version of the driver would be a good start. I'm not sure how to do this, though. I haven't had great luck getting responses to bugs that I put into Red Hat's bugzilla, let alone RFEs.
There's also the fact that the Fedora package contains multiple builds of the driver, for use with multiple JVM versions; the JPackage package only contains a single build (JDBC 3?). So even if the JPackage RPM were updated to a later driver version, there's a case for not replacing the Fedora package.
Out of curiosity, what distributions *don't* include the PostgreSQL JDBC drivers? (I.e. why does the JPackage RPM exist?)
Thanks!
On Wed, 2005-06-29 at 07:45 -0500, Ian Pilcher wrote:
Ville Skyttä wrote:
IMO that would be too much dictating local policies from our part, and subject to inherent distributed bitrot because folks usually download jpackage.repo only once. And I'm sure this stuff would not be limited to postgresql-jdbc.
I don't understand your argument. Are you saying that the file can never be changed?
No, I'm saying that once someone has downloaded and installed the file, it's currently very unlikely that (s)he'll be downloading it again later even if we'd keep frequently fine tuning it on the JPackage website.
Probably, it should be put into it's own package in the Fedora repos.
That could help some, yes.
But the *.repo files are configuration files, and the first thing I do after installing one (no matter where it comes from, packaged or not) is to remove the mirrorlist key and make it use a nearby fixed mirror.
So, after an updated jpackage.repo appears from a package, I'd have to remember to diff my local changes against it from .rpmsave, or rather probably from .rpmnew, and apply as appropriate. I'm not sure if this is really less work than just keeping the exclusions up to date the way I prefer and need, without getting packaged jpackage.repo updates at all.
So, it can be done, but the way I see it, it's not a silver bullet.
There's a larger question here. What is the "co-existence strategy" for JPackage and Fedora Core?
That question is better answered by people who have been more active here lately, but my observation is that the current reality is more or less "the end user gets to choose and configure".
Out of curiosity, what distributions *don't* include the PostgreSQL JDBC drivers? (I.e. why does the JPackage RPM exist?)
Dunno.
Ian Pilcher i.pilcher@comcast.net wrote:
Out of curiosity, what distributions *don't* include the PostgreSQL JDBC drivers? (I.e. why does the JPackage RPM exist?)
How were distros including these if java didn't really work until recently? Were they really compiled with gcj? (I guess it depends on the distro). Also, I recall that the names of the jars were strange, such that there was no way to detect the jar name you needed (say, across distros).
java-devel@lists.fedoraproject.org