Re: Wrong link not pointing to the release tarball

On Friday 22 of January 2016 17:30:59 Vladimir Sitnikov wrote:
> >[1] http://pkgs.fedoraproject.org/cgit/rpms/postgresql-jdbc.git/tree/postgresql-jdbc.spec
>
> >37:  Version: 9.4.%{upstreamrel}
>
> It should be %{upstreamver}, shouldn't it?

There used to be typo -- dot vs. dash, in RPM world, you can not have dash
within "Release" tag.  You have *strict* NAME-VERSION-RELEASE, while the
only component which can contain dash is NAME.  Based on this principle is
built most of the stuff in RPM distributions.  Can here

> ># ASL 2.0 applies only to postgresql-jdbc.pom file, the rest is BSD
> >License: BSD and ASL 2.0
>
> That is strange. Which "postgresql-jdbc.pom" is referred to here?

That one which lies right along the spec file I pointed you at.  That pom
file was created in Y2009 by Tom Lane, because we needed to have "some"
pom file (at least as far as I understand, I'm not package that long ;)).
We do not change things if that is not necessary, so there we are...

> > 57: BuildRequires: ant
> > 58: BuildRequires: ant-junit
>
> I do not think we require ant.

We (Fedora) still do.  There are hacks even in the '*.spec' file to make
the package built .. unfortunately.  We were not able to build with maven,
and other distros seem to be even behind use.

> >85: find -name "*.jar" -or -name "*.class" | xargs rm -f
>
> We have *.class files for a good reason: they include gettext translations.
> If you absolutely require to kill that, you need to add "mvn
> -Ptranslate compile" step to perform "gettext" step.
> However, that would void "built from the same git source" statement.

This needs to be done, really.  That is for our users -- we can prove them
that no precompiled code is used, because that is very often issue of Java
package upstreams.  I would reconsider the need of *any* pre-build files
within _source_ tarball -- because precompiled java files are not sources
anymore.

> >111: ln -s postgresql-jdbc.jar postgresql-jdbc2.jar
>
> That is somewhat risky, since the new jar is not usable for old JRE.
> In other words, if a software exists that uses Java 5 and jdbc2.jar,
> then newly build jar is not compatible with it.
>
> In order to build jre7, and jre6-compatible jars, separate build steps
> should be used.
> We have https://github.com/pgjdbc/pgjdbc-jre7 & jre6 for that.

Argh, OK.  I do not see that deep to see the runtime differences -- but I
bet we should remove the compatibility symlinks, right?  As nobody
complained so far I bet nobody uses them.

Vladmir, thanks for the review.  I do not object, its far from perfect --
it worked with very old release tarball;  and we are off topic.  I've seen
Dave fixed the link, so I bet you'll keep that format in future releases
too, which is *perfect*.

Thanks guys,
Pavel