Thread: Adding PGInstaller to the Downloads section

On 2018-08-28 13:39, Dave Page wrote:
<snip>
> I did;
> 
> *==>** The following existing directories will be made group writable:*
> 
> /usr/local/bin
> 
> /usr/local/lib
> 
> /usr/local/share
> 
> /usr/local/var
> 
> *==>** The following existing directories will have their owner set to 
> *
> *dpage*:
> 
> /usr/local/bin
> 
> /usr/local/lib
> 
> /usr/local/share
> 
> /usr/local/var
> 
> *==>** The following existing directories will have their group set to 
> *
> *admin*:
> 
> /usr/local/bin
> 
> /usr/local/lib
> 
> /usr/local/share
> 
> /usr/local/var
> 
> I would rather we don't list a distro, than list one that we have to 
> put
> security warnings against.

Isn't OSX/macOS considered a "single user" system for the vast majority 
of its users?

Note - I'm meaning "single person has access to the machine", rather 
than talking about the process separation model.

For a single user machine, the above setup doesn't seem terrible.  It's 
not giving world writeable access, it's just claiming ownership of 
otherwise unused directories for the main users group.

?

Anyone using OSX/macOS in multi-user fashion is probably going to hit 
other issues too (eg other people's apps in /Applications), and probably 
:) avoids Homebrew.

+ Justin

On Tue, Aug 28, 2018 at 01:19:28PM -0400, Jonathan Katz wrote:
>     On Aug 28, 2018, at 1:06 PM, Magnus Hagander <magnus@hagander.net> wrote:
>     Whether it's the EDB one or another one is a separate discussion, but we've
>     been recommending the EDB one for a long time and none of our users have
>     (AFAIK) complained about it (except when download servers have been down.
>     Personally I'd really like to see the binaries hosted on the postgresql.org
>      servers instead, but again that's an at least partially separate
>     discussion).
> 
> Partially separate discussion, but probably a separate discussion. However,
> since you opened it up, I would say +1 for it, but I understand there are
> additional considerations the infrastructure needs to make around hosting
> that, in addition to “which installer is chosen.”

Well, if we have another installer provider who has similar or better
performance for things we care about, e.g. reliable updates, support,
_and_ is willing to host the binaries where we want them, we can switch
to them.  While it is kind of disloyal to change preferred providers, we
also didn't agree to have them be preferred forever, especially if
someone better shows up.  Of course, switching might be disruptive for
our installers uses, so we have to consider that too.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On 2018-08-28 18:32, Bruce Momjian wrote:
> On Tue, Aug 28, 2018 at 01:19:28PM -0400, Jonathan Katz wrote:
>>     On Aug 28, 2018, at 1:06 PM, Magnus Hagander <magnus@hagander.net> 
>> wrote:
>>     Whether it's the EDB one or another one is a separate discussion, 
>> but we've
>>     been recommending the EDB one for a long time and none of our 
>> users have
>>     (AFAIK) complained about it (except when download servers have 
>> been down.
>>     Personally I'd really like to see the binaries hosted on the 
>> postgresql.org
>>      servers instead, but again that's an at least partially separate
>>     discussion).
>> 
>> Partially separate discussion, but probably a separate discussion. 
>> However,
>> since you opened it up, I would say +1 for it, but I understand there 
>> are
>> additional considerations the infrastructure needs to make around 
>> hosting
>> that, in addition to “which installer is chosen.”
> 
> Well, if we have another installer provider who has similar or better
> performance for things we care about, e.g. reliable updates, support,
> _and_ is willing to host the binaries where we want them, we can switch
> to them.  While it is kind of disloyal to change preferred providers, 
> we
> also didn't agree to have them be preferred forever, especially if
> someone better shows up.  Of course, switching might be disruptive for
> our installers uses, so we have to consider that too.

An alternative approach would be for us ("the project") to build 
official
installers ourselves, with those being the recommended ones.

Whether it be 100% volunteer based, someone we hire (several people have
pointed out we're not short of funds), or whatever.  Just from the 
"neutral
third party" (not vendor owned) perspective. ;)

+ Justin

On Tue, Aug 28, 2018 at 08:01:12PM +0100, Justin Clift wrote:
> On 2018-08-28 18:32, Bruce Momjian wrote:
> >Well, if we have another installer provider who has similar or better
> >performance for things we care about, e.g. reliable updates, support,
> >_and_ is willing to host the binaries where we want them, we can switch
> >to them.  While it is kind of disloyal to change preferred providers, we
> >also didn't agree to have them be preferred forever, especially if
> >someone better shows up.  Of course, switching might be disruptive for
> >our installers uses, so we have to consider that too.
> 
> An alternative approach would be for us ("the project") to build official
> installers ourselves, with those being the recommended ones.

Uh, we used to do that but found the user support overhead too much.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On 2018-08-28 20:06, Bruce Momjian wrote:
> On Tue, Aug 28, 2018 at 08:01:12PM +0100, Justin Clift wrote:
>> On 2018-08-28 18:32, Bruce Momjian wrote:
>> >Well, if we have another installer provider who has similar or better
>> >performance for things we care about, e.g. reliable updates, support,
>> >_and_ is willing to host the binaries where we want them, we can switch
>> >to them.  While it is kind of disloyal to change preferred providers, we
>> >also didn't agree to have them be preferred forever, especially if
>> >someone better shows up.  Of course, switching might be disruptive for
>> >our installers uses, so we have to consider that too.
>> 
>> An alternative approach would be for us ("the project") to build 
>> official
>> installers ourselves, with those being the recommended ones.
> 
> Uh, we used to do that but found the user support overhead too much.

No worries, was just a thought. :)

+ Justin

On 8/28/18 3:15 PM, Justin Clift wrote:
> On 2018-08-28 20:06, Bruce Momjian wrote:
>> On Tue, Aug 28, 2018 at 08:01:12PM +0100, Justin Clift wrote:
>>> On 2018-08-28 18:32, Bruce Momjian wrote:
>>> >Well, if we have another installer provider who has similar or better
>>> >performance for things we care about, e.g. reliable updates, support,
>>> >_and_ is willing to host the binaries where we want them, we can
>>> switch
>>> >to them.  While it is kind of disloyal to change preferred
>>> providers, we
>>> >also didn't agree to have them be preferred forever, especially if
>>> >someone better shows up.  Of course, switching might be disruptive for
>>> >our installers uses, so we have to consider that too.
>>>
>>> An alternative approach would be for us ("the project") to build
>>> official
>>> installers ourselves, with those being the recommended ones.
>>
>> Uh, we used to do that but found the user support overhead too much.
>
> No worries, was just a thought. :)

Well, a few things has changed since the decision was made, such as
tools, resources, and in some cases, people, so we do have a good
opportunity to reevaluate and see what makes sense. The success of the
yum + apt repositories also provides a template for how to manage &
support the installers.

I do understand it is a bit more involved (i.e. there are interface
components with a lot of these) but perhaps we can do what the other
packages do and install the minimum for supporting a PostgreSQL environment.

Jonathan

On Tue, Aug 28, 2018 at 03:22:25PM -0400, Jonathan Katz wrote:
> On 8/28/18 3:15 PM, Justin Clift wrote:
> > On 2018-08-28 20:06, Bruce Momjian wrote:
> >> On Tue, Aug 28, 2018 at 08:01:12PM +0100, Justin Clift wrote:
> >>> On 2018-08-28 18:32, Bruce Momjian wrote:
> >>> >Well, if we have another installer provider who has similar or better
> >>> >performance for things we care about, e.g. reliable updates, support,
> >>> >_and_ is willing to host the binaries where we want them, we can
> >>> switch
> >>> >to them.  While it is kind of disloyal to change preferred
> >>> providers, we
> >>> >also didn't agree to have them be preferred forever, especially if
> >>> >someone better shows up.  Of course, switching might be disruptive for
> >>> >our installers uses, so we have to consider that too.
> >>>
> >>> An alternative approach would be for us ("the project") to build
> >>> official
> >>> installers ourselves, with those being the recommended ones.
> >>
> >> Uh, we used to do that but found the user support overhead too much.
> >
> > No worries, was just a thought. :)
> 
> Well, a few things has changed since the decision was made, such as
> tools, resources, and in some cases, people, so we do have a good
> opportunity to reevaluate and see what makes sense. The success of the
> yum + apt repositories also provides a template for how to manage &
> support the installers.
> 
> I do understand it is a bit more involved (i.e. there are interface
> components with a lot of these) but perhaps we can do what the other
> packages do and install the minimum for supporting a PostgreSQL environment.

Sure, we can certainly reevaluate.  The biggest user support load, as I
remember, was Windows users.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

> On Aug 28, 2018, at 12:01 PM, Justin Clift <justin@postgresql.org> wrote:
>
> On 2018-08-28 18:32, Bruce Momjian wrote:
>> On Tue, Aug 28, 2018 at 01:19:28PM -0400, Jonathan Katz wrote:
>>>    On Aug 28, 2018, at 1:06 PM, Magnus Hagander <magnus@hagander.net> wrote:
>>>    Whether it's the EDB one or another one is a separate discussion, but we've
>>>    been recommending the EDB one for a long time and none of our users have
>>>    (AFAIK) complained about it (except when download servers have been down.
>>>    Personally I'd really like to see the binaries hosted on the postgresql.org
>>>     servers instead, but again that's an at least partially separate
>>>    discussion).
>>> Partially separate discussion, but probably a separate discussion. However,
>>> since you opened it up, I would say +1 for it, but I understand there are
>>> additional considerations the infrastructure needs to make around hosting
>>> that, in addition to “which installer is chosen.”
>> Well, if we have another installer provider who has similar or better
>> performance for things we care about, e.g. reliable updates, support,
>> _and_ is willing to host the binaries where we want them, we can switch
>> to them.  While it is kind of disloyal to change preferred providers, we
>> also didn't agree to have them be preferred forever, especially if
>> someone better shows up.  Of course, switching might be disruptive for
>> our installers uses, so we have to consider that too.
>
> An alternative approach would be for us ("the project") to build official
> installers ourselves, with those being the recommended ones.

That would make sense if the PGDG installers were the "best" for
some definition of such. That seems like it'd be the place to start if
we wanted to make them the preferred ones.

In the macOS world there are a wider variety of PostgreSQL installers,
with different focuses (good for development, good for production, similar
to a unix install) and they're all useful.

> Whether it be 100% volunteer based, someone we hire (several people have
> pointed out we're not short of funds), or whatever.  Just from the "neutral
> third party" (not vendor owned) perspective. ;)

If "we" wanted to put together a Windows installer it might be nice to start
with a smaller project to see what installer toolchain (e.g. wix) we wanted to
use, and what features we wanted to support.

A fairly regular request from Windows users is an installer for just the client
binaries - psql, libpq etc.. That would be a useful product in itself, as well
as a good proof of concept.

That's probably diving way off topic for -www though.

Cheers,
  Steve

On 2018-08-29 06:49, Magnus Hagander wrote:
> On Tue, Aug 28, 2018 at 9:06 PM, Bruce Momjian <bruce@momjian.us> 
> wrote:
>> On Tue, Aug 28, 2018 at 08:01:12PM +0100, Justin Clift wrote:
>> > On 2018-08-28 18:32, Bruce Momjian wrote:
>> > >Well, if we have another installer provider who has similar or better
>> > >performance for things we care about, e.g. reliable updates, support,
>> > >_and_ is willing to host the binaries where we want them, we can switch
>> > >to them.  While it is kind of disloyal to change preferred providers, we
>> > >also didn't agree to have them be preferred forever, especially if
>> > >someone better shows up.  Of course, switching might be disruptive for
>> > >our installers uses, so we have to consider that too.
>> >
>> > An alternative approach would be for us ("the project") to build official
>> > installers ourselves, with those being the recommended ones.
>> 
>> Uh, we used to do that but found the user support overhead too much.
>> 
> No, that's not the reason. The user support overhead doesn't change 
> between
> installers TBH. That changed because the new ones are simply more 
> adapted
> to user needs.
> 
> It was the maintenance burden of them that was simply too terrible. 
> Now,
> that's better today with more modern tools, but it's still not trivial. 
> So
> the first thing we'd need if we want to change that back into being
> community maintained would be volunteers to do the actual work. I'm all 
> for
> having it volunteer based like we have with apt or yum for example, but
> that needs to start with people willing to do the work.

+1

Hello,

while we are here, may I ask you www-guys  to consider our request

https://www.postgresql.org/message-id/flat/311b87dc-648e-0827-9530-18855ea63785%40postgrespro.ru#7bbed328d5cf9161eabc13885729b9fb

Best regards,
Oleg

On Tue, Sep 11, 2018 at 5:26 PM, Umair Shahid
<umair.shahid@2ndquadrant.com> wrote:
>
> On Tue, Aug 28, 2018 at 4:46 PM Umair Shahid <umair.shahid@2ndquadrant.com>
> wrote:
>>
>> Hi Dave
>> On Tue, Aug 28, 2018 at 4:01 PM Dave Page <dpage@pgadmin.org> wrote:
>>>
>>> Hi
>>>
>>> On Tue, Aug 21, 2018 at 5:57 PM, Umair Shahid
>>> <umair.shahid@2ndquadrant.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please find attached a patch to add PGInstaller to the Downloads section
>>>> of postgresql.org.
>>>>
>>>> PGInstaller offers an easy way to install PostgreSQL. We have found this
>>>> to be crucial to our customers who are used to GUI-based, click-n-point
>>>> installers on Windows and at times on macOS. PGInstaller has evolved from
>>>> 2UDA, a package that 2ndQuadrant has been working on for more than 3 years.
>>>>
>>>> 2ndQuadrant is committed to developing and actively maintaining
>>>> PGInstaller for PostgreSQL versions 9.5 and above. We have been releasing,
>>>> and will continue to release, updates in sync with the PostgreSQL community,
>>>> most recently announcing the minor release on 9-Aug. PGInstaller has also
>>>> kept up with the Beta releases for PostgreSQL 11.
>>>
>>>
>>> The first issue that I can see (or more correctly, not see), is the
>>> source code. All packages on these pages need to be 100% Open Source,
>>> including the code required to build the packages themselves (but not
>>> necessarily the tools/compilers of course). Where can the code be found?
>>
>>
>> I didn't realize that was a requirement. Let me work with the team
>> internally to open the source code.
>
>
> The source code is available here:
> https://github.com/2ndQuadrant/postgres-installer
>
>>
>>
>>>
>>>
>>> Secondly, it looks like your ordering is not quite as it should be on
>>> some pages. We list native packages first, followed by non-native, then
>>> third party packaging systems, with new additions at the end of the
>>> appropriate section to limit confusion for users (particularly those who
>>> pick the first item then later try to upgrade it).
>>>
>>> E.g. on the Ubuntu page,  it should be:
>>>
>>> PG APT Repo
>>> BigSQL DEB Packages
>>> EDB Installers
>>> 2ndQ Installers
>>>
>>> On the Mac page:
>>>
>>> EDB Installers
>>> BigSQL Installers
>>> Postgres.app
>>> 2ndQ Installers
>>>
>>> Similarly for other pages.
>>
>>
>> We can work on that.
>
>
> The attached patch has the ordering as required.
>
>>
>>
>>>
>>>
>>> Finally; "PGInstaller" is the name used by the original Windows packaging
>>> that Magnus and I used to maintain
>>> (http://pgfoundry.org/projects/pginstaller/). I for one would appreciate it
>>> if you didn't use that name, but came up with something original.
>>
>>
>> Given Magnus' email that this is not a completely dead project, I think
>> that's reasonable. I'll get back on this thread with the requested changes.
>
>
> The name has been updated to Postgres Installer.
>
>>
>>
>>>
>>>
>>> Thanks.
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>
>>
>>
>> --
>> Umair Shahid
>> Head of Marketing & Products
>> 2ndQuadrant - The team of diligent PostgreSQL experts
>> https://www.2ndQuadrant.com/
>
>
>
> --
> Umair Shahid
> Head of Marketing & Products
> 2ndQuadrant - The team of diligent PostgreSQL experts
> https://www.2ndQuadrant.com/



-- 
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Hi,

On 10/8/18 9:11 AM, Umair Shahid wrote:
>
>
> Hi. Any updates on this? 
>
> If there is specific feedback on how to make this patch better, please
> let me know. Thanks!
We're sorry this is taking some time to get to - with the major release
and some other larger pgweb projects, in addition to some of the
discussion on how to set this up, we have not been able to prioritize
it. We will get to this in the weeks after the PG11 launch.

Our plan is to focus on doing some restructuring on the downloads page -
which there appears to be consensus - before adding additional
installers. Getting this done will allow us to add the installers
shortly, if not immediately, after.

Thanks!

Jonathan

On Sat, Oct 13, 2018 at 04:20:42PM -0400, Jonathan Katz wrote:
> Hi,
> 
> On 10/8/18 9:11 AM, Umair Shahid wrote:
> > 
> > 
> > Hi. Any updates on this? 
> > 
> > If there is specific feedback on how to make this patch better, please
> > let me know. Thanks!
> We're sorry this is taking some time to get to - with the major release
> and some other larger pgweb projects, in addition to some of the
> discussion on how to set this up, we have not been able to prioritize
> it. We will get to this in the weeks after the PG11 launch.
> 
> Our plan is to focus on doing some restructuring on the downloads page -
> which there appears to be consensus - before adding additional
> installers. Getting this done will allow us to add the installers
> shortly, if not immediately, after.

Considering that Postgres Pro has been waiting almost a year, and 2nd
Quadrant a month, I am thinking we need to resolve this soon.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Hi,

On 10/17/18 2:36 AM, Umair Shahid wrote:
>
>
> On Wed, Oct 17, 2018 at 1:17 AM Magnus Hagander <magnus@hagander.net
> <mailto:magnus@hagander.net>> wrote:

>     It is definitely true that you have worked quickly to address the
>     problems that were there with the patch initially, and that is
>     definitely appreciated. But just like with PostgreSQL itself, that's
>     no guarantee that it will get in.
>
>     It's just like the main PostgreSQL sourcecode -- we don't apply
>     patches even though the author updates them quickly based on
>     comments if it's determined that they are counterproductive to the
>     bigger goal of the product. It's the same here, just for the website.

Given some other flurry on -www this week with patches, I want to write
in to say that this thread has not been forgotten. Based on various
discussions on-list, off-list, and at PGConf.EU, designing a patch
(likely patch set) for this will take some work and will most certainly
require review and discussion.

I went to make an initial attempt while at PGConf.EU and saw the design
scope would be a bit more complicated than one would think to ensure
it's clear for our users how to download the packages. I am hoping to
have something more concrete to share after the upcoming cumulative update.

Thanks,

Jonathan

On Tue, Nov 6, 2018 at 12:52 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> Hi,
>
> On 10/17/18 2:36 AM, Umair Shahid wrote:
> >
> >
> > On Wed, Oct 17, 2018 at 1:17 AM Magnus Hagander <magnus@hagander.net
> > <mailto:magnus@hagander.net>> wrote:
>
> >     It is definitely true that you have worked quickly to address the
> >     problems that were there with the patch initially, and that is
> >     definitely appreciated. But just like with PostgreSQL itself, that's
> >     no guarantee that it will get in.
> >
> >     It's just like the main PostgreSQL sourcecode -- we don't apply
> >     patches even though the author updates them quickly based on
> >     comments if it's determined that they are counterproductive to the
> >     bigger goal of the product. It's the same here, just for the website.
>
> Given some other flurry on -www this week with patches, I want to write
> in to say that this thread has not been forgotten. Based on various
> discussions on-list, off-list, and at PGConf.EU, designing a patch
> (likely patch set) for this will take some work and will most certainly
> require review and discussion.
>
> I went to make an initial attempt while at PGConf.EU and saw the design
> scope would be a bit more complicated than one would think to ensure
> it's clear for our users how to download the packages. I am hoping to
> have something more concrete to share after the upcoming cumulative update.

Trying to revive this thread.  My personal interest is to have link
from download page to our windows installer
https://postgrespro.com/windows. There was already discussion what we
should have on this page and what's not, so I don't understand the
problem of updating that page.

>
> Thanks,
>
> Jonathan
>


-- 
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company