Re: [HACKERS] Packaging of postgresql-jdbc

Thanks a lot, I appreciate your concerns and I mostly agree with you. Let
me answer just quickly to the important points which need to be
underlined. I could more, but I would repeat myself:

I do agree that the fork is not optimal, but that is the
only way to go to keep the distribution sane, consistent.
At least as long as upstream considers downstream packaging
as something which is not important.

On Wednesday 17 of February 2016 19:41:52 Álvaro Hernández Tortosa wrote:
> The only other real alternative is change the code to work around
> waffle, and after a long time debating I have seen nobody to come up
> with a fix for this.

Please 's/work-around/make soft-dependency/' and specify that the work
must be done upstream.

> > I believe this has been discussed before, and Pavel Kajaba already
> > worked on it .. but this is not acceptable by upstream.
>
> Yeah, so we have to work around it. That's why we are suggesting
> this alternative.

This _is good alternative_ which needs, however, to be done on one place.
More eyes see more bugs -- so the "hacks" will be done properly if
distributions concentrate on one place. At least those upstreams who are
interested.

> > Don't take me wrong -- it is easier to do the patching your way, but on
> > one place! Then take the tarball and you are done.
>
> If I understood it correctly, the RPM specs specifically allow (and
> I believe is common place) to patch upstream software, to adapt it to
> the specificities of RPM packaging. I believe this patch perfectly
> belongs to this category.

No, this is not possible. If you fix our spec file to apply some
downstream patch, you fix only RPM.

> Good news is that to do this, we don't need any upstream approval :)

That is what the fork is meant for. From that forked code we can generate
(the only one - self-standing) tarball -- which anybody can take and use
to build from source easily (fixed build scripts).

> >> Other distros will surely benefit anyway, as the process of
> >> patching a source rpm/deb/whatever only differs in implementation
> >> details (how you do it), not on the concept of doing it.
> > Well, how exactly you expect this patch to be applied? Because deb
> > maintainers usually do not watch RPM packaging and vice versa.
>
> Well, when Debian maintainers would ask pgjdcb, the same way as you
> did, we will point them to the solution applied to the RPM, which will
> be already working, so that they could apply the same technique
> --shouldn't be hard.

Yeah, I'll ping (not only) Debian guys soon. We should do the hacking
technique together and the constant way.

> We both agree :) But forking pgjdbc to create pgjdbc-foss is, to
> me, much more DRY than a tiny patch that might be distribution-dependant.

The patches we plan to support in fork are distribution-independent.
Otherwise it would make no sense to concentrate the work.

> I care a lot about FOSS principles, and that's the main reason if
> we rewrite the interfaces, they will be completely FOSS.

Thanks that you do care here.. foss alternative is acceptable, but see
below it is still not perfect. The dependancy hell -- you should be able
to build/test/deploy your software without software you actually don't
need.

> > End users would be able to use 'pgdjbc-foss' or 'pgjdbc-foss-osgi' (KISS).
>
> I think this will make users nuts. There will be three versions of
> the driver:
>
> - One in the official website (pgjdbc), not in Fedora
> - One called pgjdbc-foss, only in Fedora, not mentioned anywhere else
> - One called pgjdbc-foss-osgi, only in Fedora, not mentioned anywhere
> else, which will create even confusion against the non-osgi one

This is all unfortunate, I agree with you. I would still prefer to have
fixed upstream so it is re-distributable correctly.

On the other hand, that is what using hard-to-package-correctly
licenses/software result in, and anybody should be aware of.

> Plus the huge burden of maintaining two! forks of pgjdbc.

This is not a problem. Patching out the 'osgi.enterprise' and 'waffle' is
easy enough to take care of. And all distros will be sure that it is done
the right way (and if not, somebody needs to fix it or everybody will
loose -- thats why we need to be together).

> I believe it's more KISS to just re-write the OSGI stuff used in
> pgjdbc, license that PostgreSQL, and you're good to go, with a pure FOSS
> package.

Right, it is the right - foss way. But I still claim this is useless
effort. If the osgi was an issue, people would care to have up-2-date
alternatives in GNU/Linux ecosystem already. So ... repeating myself ...
to make it super perfect, :) users should be able to build the software
without osgi. You can look how postgresql server is built! (tons of
options available during build, nobody tries to pretend that all the
functionality needs to be built in, _everywhere_ OR _nowhere_). Even if
you switch to free alternative to osgi.enterprise, 90% of the packagers
will still patch it out .. and there you go -- something is wrong and the
work-around needs to be done on one place.

> >> We definitely don't know how much or less users use this, but
> >> removing something that works and might be used is what may cause
> >> trouble. Specially, if it is just a few hours of work away to fix the
> >> licensing issue.
> > Oh, I see what you mean :) now -- but those licensing issues should be
> > fixed upstream..
>
> Right. We can work on fixing them and submitting a PR.

Let's wait for upstream.

> > I still don't get the reason why there can't be single one tarball. It is
> > a problem, every distro is going to build the package in two-steps.
> > Gentoo guys do build their packages themselves!
>
> I think this is a matter of taste.

Disagree :( it is a lot of thinking to make the packaging right; and
nobody convinced me that this is actually necessary. U just agree that
this issue can be worked around...

> I believe having a separate
> package for the osgi interfaces that you are "copying" to provide a
> compatibility layer belong to a separate project, and hence two
> tarballs.

I must disagree here. The osgi as opt-out can't exist, so the osgi in
separate "layer above" pgjdbc (not talking about copying the code) sounds
like natural solution.

> But if that would be a showstopper, it could be integrated
> into pgjdbc itself. But I'd wait for other's (pgjdbc core) opinion here
> before doing that.

That is what we need to do! :)

Pavel