Re: Step towards being able to build on Linux (Pull request #435)

Hi all.

I'm not going to reply to the low-level stuff mentioned here, as
there are many bits to analyze. But I still want to give my general opinion.

pgjdbc has improved in the last year or so significantly, and a lot
of infrastructure has made it possible, like new features, CI and
Maven-ization. Thanks to everyone involved. So now it's not a bad time
to look at other issues/priorities, other than the "usual suspects",
like performance and new features.

And I think packaging is definitely one of them. It blows my mind
that RHEL, Fedora or Debian users are using significantly outdated
versions of the driver because of a packaging issue. Why do we develop
so many cool stuff for other users not to have a simple means for using
it? It's probably nobody's specific fault, but this is something that
should be fixed with high priority, IMHO.

So please lets sit down and try to constructively fix this. As far
as I understand, we (all) should mainly work on:

- Understand more clearly packaging requirements (what Vladimir referred
to as gathering the requirements). Is there a guide, document or other
reference which we may look at?

- Analyze our pom's dependencies and study them one by one, and their
transitive dependencies, to check: (for the specific versions used)
* Whether they are already packaged in RH/Fedora
* What's their license, check it is effectively open source, and
find if the source is available. And how it is built.

- Understand how other Maven-based projects are built for RH/Fedora

And then, only then, figure out all the low-level technical details
to see how to fix them.

Am I missing something else? What do you think?

Cheers,

Álvaro

On 20/01/16 14:03, Pavel Raiskup wrote:
> On Wednesday 20 of January 2016 18:18:16 Vladimir Sitnikov wrote:
>>> I'm asking you - as Java hacker - how this is
>>> _normally_ done.
>> Maven profile. See [1].
> Thanks.
>
>>> That is unlucky .. who should I ask? At least adding new dependency is
>>> big issue every committer should take into account. I'm not sure about
>>> licensing too -- and thats why we can't provide jdbc with osgi support.
>> Frankly speaking, I've no idea how that is usually managed.
>> It looks like pgjdbc does not force to sign CLAs when accepting patches.
>>
>> I'm not sure why you pay so much attention to osgi while completely
>> ignore the fact that pgjdbc includes lots of contributions (from
>> random people) itself.
> Contributing to project with "PostgreSQL" license is clear; using it is
> clear either. As a user, I can trust you (== software provider) that the
> code you provide is really "PostgreSQL" licensed -- on distribution
> level we must properly check/review that this is truth, but that is fine.
>
> (hard) dependency on randomly licenced project OTOH can make otherwise
> perfectly well licenced open source project unusable for me as open-source
> user. What would be worse: Two dependencies on two proprietary licenses
> might make the project (legally) unusable. At least as far as I
> understand.
>
> That is why the licensing is important from user's perspective, and why SW
> providers should be aware of that POV.
>
>> The osgi jars in question are licensed under Apache 2.0.
>> jcp is Apache 2.0 as well.
> IANAL, but Apache 2.0 is fine license if we *have* the right source code
> (which is not guaranteed by Apache 2.0 itself, neither osgi, afaik), but
> again - IANAL. Do we have source?
>
> But to other point -- if I understand it right, only some kind of API for
> "jar-file" propagation in osgi-capable system is used.
> Is this too candidate for opt-out in maven profile? That would simplify
> things.
>
>>> Yes, we do manual reviews. By "software binary blob" I meant code
>>> (which can be executed) which may, e.g., infect my machine.
>> I do not want to stretch that, but I wonder if you call "sql statement
>> inside a java code" a "software binary blob" "which can be executed in
>> backend" and "infect the machine via integer overflow or whatever".
> It is source code; thus (if not obfuscated) nobody is blocked from
> looking at the code and decide whether that "is"/"is not" malicious
> software. Or whether it has compatible license. Pre-compiled software is
> not human readable usually, similarly obfuscated code -- so that I meant
> by "binary".
>
>> I mean: what if I convert osgi.jar into a java file into a form of some
>> select statements? Would it heal your case?
> That sounds like obfuscation.
>
> If you converted the osgi.jar file into properly licensed SQL source code,
> that it would be probably fine :).
>
>>> Pavel sent you an approach. Except the testsuite issue?
>> Yes. Without a testcase I cannot understand what that commit is trying
>> to accomplish.
> We try to move one dependency from 'hard' => 'optional', because that is
> hard-to-get-into-linux (the right way). But sounds fair, as I understand
> it right -- in Travis is something like Ubuntu environment, right? There
> should be easy to remove '*.jar' (which is redundant anyway) file to make
> such test.
>
> Thanks Vladimir for the answer,
> Pavel
>
>
>