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

Alvaro,

Thanks for summarizing this. I agree completely. I think the only two items
that we have to deal with are osgi, and waffle.

I'm curious how may people actually use osgi? Can this be a sub-project
that builds an osgi compatible jar ?

As for waffle, it seems like using some kind of Factory method should work
there?

If we address these two issues would this be compatible with RH/Fedora ?

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

On 20 January 2016 at 19:30, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com>
wrote:

>
> 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
>>
>>
>>
>>
>