Re: Complicated re-distribution of pgjdbc the "open source way"

Well, just please make sure it's different artifact (e.g. by different
version), so that it wont mix up.

Best regards, Vitalii Tymchyshyn

Вт, 8 бер. 2016 09:10 користувач Dave Cramer <pg(at)fastcrypt(dot)com> пише:

> As Craig has said, the simplest solution is a separate maven profile. This
> is something we would endorse
>
> Dave Cramer
>
> davec(at)postgresintl(dot)com
> www.postgresintl.com
>
> On 8 March 2016 at 08:51, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>
>>
>>
>> On 8 March 2016 at 20:41, Pavel Raiskup <praiskup(at)redhat(dot)com> wrote:
>>
>> I appreciate any work done the open source way.
>>>
>>
>> I take issue with that (in the context of this conversation).
>>
>> I think you are conflating "the Fedora / Debian free-software purist
>> Linux distro packaging way" with "the open source way".
>>
>> There is not one "open source way". There are many. Yours is not the only
>> one, and I think you're getting a few people off-side by refusing to
>> acknowledge that just because you want to do things a particular way that
>> doesn't make your way inherently the only correct one and everyone else's
>> wrong. Or maybe I'm just reading your tone wrong and being too prickly, but
>> offlist discussion confirms to me that I'm not the only one if so.
>>
>> Maven is open source. Waffle is open source. JBoss AS is open source.
>> OpenOffice is open source, yet causes a lot of packaging pain too. Perl is
>> open source, but CPAN makes packagers want to cry (I know, I've had to
>> package CPAN modules). Ruby is open source, but the RubyGems system's
>> interaction with packaging can be agonizing.
>>
>> Packaging can be painful. Sometimes that's due to people doing insane
>> things in the software you're trying to package. Sometimes that's due to
>> necessary-but-frustrating-and-limiting distro/packaging policies. Sometimes
>> it's due to more fundamental differences in the models of how distro
>> packaging works vs how some other software works. If it's hard to package
>> that doesn't make it wrong.
>>
>> I think the way forward here is to propose a build profile set up that
>> lets you omit the things you want to omit, including tests showing that the
>> omitted features fail in a well-specified and graceful way. I at least have
>> no objection to running >1 build configuration in TravisCI etc.
>>
>> --
>> Craig Ringer http://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Training & Services
>>
>
>