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