Subject: Linux Downloads page change

From: Scott Mead <[email-masked]>
Date: Sat, 7 Jul 2012 12:26:32 -0400

Hey all,

    The Linux binary downloads page seems to have changed, eliminating the
cross-distribution, unified RPM's as a download option.  Is this something
simple that got missed in a recent check-in?

--Scott

---

From: Magnus Hagander <[email-masked]>
Date: Sat, 7 Jul 2012 18:50:32 +0200

> simple that got missed in a recent check-in?

Hi!

They are all on the general download page, under third party distributions.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

---

From: Scott Mead <[email-masked]>
Date: Sat, 7 Jul 2012 13:06:37 -0400

On Saturday, July 7, 2012, Magnus Hagander wrote:

> On Sat, Jul 7, 2012 at 6:26 PM, Scott Mead <[email-masked]<javascript:;>>
> wrote:
> > Hey all,
> >

 Those are our developer bundles that include postgres along with different
application servers.  We also have production/ops server rpms that used to
appear on the Linux download page.

--Scott

---

From: Devrim GÜNDÜZ <[email-masked]>
Date: Sat, 07 Jul 2012 23:23:10 +0300

On Sat, 2012-07-07 at 13:06 -0400, Scott Mead wrote:
>  Those are our developer bundles that include postgres along with
> different application servers.  We also have production/ops server
> rpms that used to appear on the Linux download page. 

That reminds me... Why do we give link to some binary RPMs, where SRPMs
are not available?

Regards,
-- 
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

---

From: Scott Mead <[email-masked]>
Date: Sat, 7 Jul 2012 23:05:13 -0400

> That reminds me... Why do we give link to some binary RPMs, where SRPMs

Those RPMs are built using the certified binaries that the community distributes already, but simplifies installation in deeply firewalled / headless server environments.  They also allow for side-by-side installs of major versions ( pg_upgrade compatible ) and have since their inception.   

--Scott

---

From: Magnus Hagander <[email-masked]>
Date: Sun, 8 Jul 2012 11:43:05 +0200

> appear on the Linux download page.

I wasn't even aware there were different ones - there's your explanation.

These are the ones listed on the same page, right?

Is there a documentation page somewhere outlining the differences
between these and the community binaries?

---

From: Devrim GÜNDÜZ <[email-masked]>
Date: Sun, 08 Jul 2012 23:56:52 +0300

On Sat, 2012-07-07 at 23:05 -0400, Scott Mead wrote:
> Those RPMs are built using the certified binaries that the community
> distributes already, but simplifies installation in deeply
> firewalled / headless server environments.  They also allow for
> side-by-side installs of major versions ( pg_upgrade compatible ) and
> have since their inception.   

That is not an answer to my question. Why don't you distribute the SRPM?
How can someone make sure that the RPMs do not include some more extra
code?
-- 
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 09:31:32 +0100

> How can someone make sure that the RPMs do not include some more extra

I assume the SRPM isn't provided because the binaries that are
packaged are actually the ones that EDB build (and I wouldn't be
surprised if they're generated with BitRock InstallBuilder, so there
wouldn't be an SRPM anyway).

That aside though, the code must be 100% open source to be listed on
those download pages; Scottie, where can people find the spec files,
BitRock XML files or whatever?

Also, I took a quick look at the GIT history for the download pages,
and as far as I can see there weren't any links to these RPMs in the
past, so I'm not sure what has been removed exactly. Scott; can you
point me at the commit that changed what you're referring to please?

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 9 Jul 2012 10:42:06 +0200

> wouldn't be an SRPM anyway).

BitRock can generate RPMs these days? Neat!

> BitRock XML files or whatever?

While I agree with that requirement in general, we should apply it
fairly. AFAICT the latest release of the EDB installers that had
sourcecode with it was 9.0.2 - I have a hard time seeing that nothing
would've changed since... None of the changes that have been discussed
on the lists here in the past couple of months are anywhere to be
seen.. So should we remove the EDB installers from the page as well?

> point me at the commit that changed what you're referring to please?

I assume he's referring to:
-<p><a href="http://www.openscg.org/postgresql/packages">Download</a>
the packages from OpenSCG.<
-<p><i>The multi-platform binary packages are maintained by <a
href="http://www.openscg.org">Open

from commit b282714a097f767b258e469fb80225b638864a19. They used to be
on the "generic linux" page, as well as on the "generic downloads
page". They are now only on the "generic downloads page".

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 10:09:22 +0100

> BitRock can generate RPMs these days? Neat!

It's been able to do RPMs and DEBs as long as I've been using it. I
tried generating them from our builds, but there's too much
interactivity at different points in the installers, and neither the
RPM or DEB formats can handle it.

> seen.. So should we remove the EDB installers from the page as well?

The EDB installers are open source, and have been since they were
first published. You can get the code for all branches from
http://git.postgresql.org/gitweb/?p=edb-installers.git;a=summary, and
that includes not just the installer files, but the entire build
framework. The most recent commit is to the 9.2 branch, from Friday.

I'm not sure why you would think I'd push for a different rule for
OpenSCG than EDB - I've always made a point of trying to apply the
same standards to all our corporate contributors - as a core team
member and a senior member of staff at EDB not only is it the right
thing to do, but it's the only way I can function in both roles. I'm a
little offended that you would suggest otherwise.

> page". They are now only on the "generic downloads page".

Oh, I see it now. Not sure how I missed that.

---

From: Scott Mead <[email-masked]>
Date: Mon, 9 Jul 2012 05:13:21 -0400

> > wouldn't be an SRPM anyway).

+1

> > BitRock XML files or whatever?

  In the past we have always provided them upon request ( we were asked
only nce :).  But we can work that out, no problem.

> page". They are now only on the "generic downloads page".

Exactly, this is the link I was talking about.

--Scottie

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 9 Jul 2012 11:31:43 +0200

On Mon, Jul 9, 2012 at 11:13 AM, Scott Mead <[email-masked]> wrote:
>   In the past we have always provided them upon request ( we were asked only
> nce :).  But we can work that out, no problem.

Yes, please look into that.

> Exactly, this is the link I was talking about.

Given that the whole idea of the redesign is to help people figure out
why they should choose the different options, can you provide a patch
to that page that actually includes a good description of *why* these
would be preferable to the standard RPMs?

---

From: Scott Mead <[email-masked]>
Date: Mon, 9 Jul 2012 05:36:01 -0400

> >   In the past we have always provided them upon request ( we were asked
only
> would be preferable to the standard RPMs?

Absolutely, I'm boarding a flight now, but will work on it once I hit
10,000 ft.

--Scottie

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 9 Jul 2012 11:36:17 +0200

Pah, got denied-post on -www for that email due to it being too large.
Sorry about that - repost, with a link instead - the referenced image
can be found at
http://www.hagander.net/tmp/s_2012-07-09-01-3c6e87.png.

//Magnus

On Mon, Jul 9, 2012 at 11:30 AM, Magnus Hagander <[email-masked]> wrote:
> On Mon, Jul 9, 2012 at 11:09 AM, Dave Page <[email-masked]> wrote:
> Cool. I had no idea :) But yah, particularly the RPMs are pretty picky
> about interactivity (for good reasons from their perspective, of
> course, but nevertheless quite picky)
>
>
> Attached is a screenshot showing what this page looked like when I
> sent that email. So someone pushed all those changes *after* I sent
> that email, in what looks like an attempt to dispute that statement.
> While we don't have log extracts showing the exact times (should
> probably fix that in the pggit code), there is certainly a push shown
> around 9AM UTC this morning... (and it shows that between this push
> and the previous *of any activity at all* on that repository, there
> have been another 5189 operations on git.postgresql.org - around 3500
> pushes, though that includes pushes from the mirror of the main
> postgresql git repo, so it's a little bit inflated. but it pretty
> clearly matches up to the "no activity in 18 months" that the web
> interface showed)
>
> I know they're *intended* to be opensource. But the normal status is
> they're lagging behind a year or more, so I'm not sure I consider it
> open... My experience shows that whenever I'm looking for something,
> it's not up to date, and it's only pushed when I point it out. It may
> well be that it's pushed at other times as wel of course - but you
> can't really claim it's pushed regularly.
>
> I normally wouldn't think you would, but it certainly sounded like
> that, given exactly what that repository looked like this morning -
> and has looked like pretty much every time I've looked at it recently.
> Which was "the installers were once dumped as opensource to make it
> look good, but we don't really care about them being open".
>
> And frankly, I'm a little offended by whomever made that push into the
> repository to dispute my statement, without claiming responsibility
> for doing so. To me, it's rather obvious it was done as a direct
> response to my email. Given the perfect timing. Whoever did it.
>
> So what *is* the intended policy for that repo? It's clearly not the
> primary repo for the edb installers but just a mirror. Which has
> received a total of 50 pushes *since the creation of the new
> git.postgresql.org*, years ago.  So it's clearly not mirrored in
> anything near real time. So when *does* it get pushed, aside from when
> somebody complains?
>
> --
>  Magnus Hagander

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 10:44:26 +0100

> clearly matches up to the "no activity in 18 months" that the web

It gets pushed periodically when I remember to do it (or someone
reminds me), which I guess you've forgotten given that we've had this
exact same discussion before. Yes, I pushed it when you reminded me a
moment ago - and this time remembered to also push the 9.2 branch
which previously hadn't been pushed because it needs to be done
explicitly the first time which I had forgotten to do in the past.
That's where the vast majority of activity has been over recent
months, except the last 3 weeks or so where there have been numerous
bug fixes in the back branches as we've been updating the add-ons that
are available through StackBuilder.

> can't really claim it's pushed regularly.

No, I never have claimed it's pushed regularly. I've always said it's
pushed when I remember or when someone reminds me. The point is that
it is pushed, and has been on more than one occasion since 9.0.2 was
released - which should be obvious if you look towards the bottom of
your screenshot.

> response to my email. Given the perfect timing. Whoever did it.

It was. You reminded me. As you've done in the past. I made no claim
that I push that repo on any regular schedule - merely that I try to
remember to keep it up to date, and the code is available under an
open source licence.

> anything near real time. So when *does* it get pushed, aside from when

As I said, when I remember to do it. As I've told you in the past.

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 10:47:08 +0100

> released - which should be obvious if you look towards the bottom of

BTW; the reason that you see 9.0.2 in the commit log there is that
right after 9.0.2 was released, we stopped using the master branch for
anything. We now use named branches for all versions, so there is no
recent activity in master, only in the REL-X_Y branches.

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 9 Jul 2012 11:49:21 +0200

> are available through StackBuilder.

We have had the discussion before, and I was pretty sure it ended up
in "yes, it should be fixed". But it doesn't change the fact that the
repository claimed there had been no changes for *7 months*, certainly
not 3 days. Which also agrees very well with the logs on
git.postgresql.org.

So clearly there is something that doesn't work in this process.

> pushed when I remember or when someone reminds me. The point is that

In that case, can we get it done regularly, so it can actually be
considered open?

> released - which should be obvious if you look towards the bottom of

Yeah. I guess you're just not bothering to tag releases anymore? that
confused me on that point.

> remember to keep it up to date, and the code is available under an

Well, IMNSHO, just being available under an open source license *if
asked for*, should be well below where a reasonable bar would be put
for this.

But in treating people the same - I just asked Scottie to make sure
that they're not available just when asked for, but all the time. Can
you do the same?

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 11:13:18 +0100

> not 3 days. Which also agrees very well with the logs on

I'm not disputing that, and never have.

> So clearly there is something that doesn't work in this process.

It works exactly as it always has. No, I haven't got round to
automating the pushes yet, largely because I've had 1001 other things
to do, the vast majority of which will benefit far more users and
community members in one way or another. I wasn't aware that you
considered this to be such a high priority item compared to all the
other tasks I have on my plate.

> confused me on that point.

Yes, we tag them. I just forgot that GIT pulls tags automatically, but
doesn't push them. I've corrected that now.

> asked for*, should be well below where a reasonable bar would be put

Maybe, but that's a different discussion. By your own admission you've
been well aware that we made the installers available under an OSS
licence in this way for a long time which implies consent, casual
discussion about improving the push frequency aside - as is the norm
in community matters. You certainly haven't nudged me about this, or
made me aware (until now) that you consider it to be a high priority.

> that they're not available just when asked for, but all the time. Can

Sure, I'll bump it up the list and try to do it today. What do you
consider more important, this or the CFP?

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 9 Jul 2012 12:22:48 +0200

> other tasks I have on my plate.

Given that I don't know what else is on your plate (except for some
tiny parts), that's kind of hard to state. I *have* asked for it for
years...

> doesn't push them. I've corrected that now.

Ah, that explains it even better.

> made me aware (until now) that you consider it to be a high priority.

I have said many times that I don't consider it open enough if it's
only published "every now and then". Mainly in discussions about
*other* products, of course, but in this relation as well. And I have
said that it's a problem referring people to a repository that's not
up to date when they ask for how things are built and/or intended to
work.

> consider more important, this or the CFP?

The cfp, for short term, since it's more time critical. If getting it
done properly is just on your list, that's good enough for me - since
clearly it wasn't on your list earlier, even though I thought it was.

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 11:28:11 +0100

> tiny parts), that's kind of hard to state. I *have* asked for it for

Well, just things like my parts in PostgreSQL 9.2, pgAdmin 1.16,
PGConf.EU, pgFoundry etc. most of which I'm sure you're aware of. I
wouldn't call them tiny though, when totalled up.

---

From: Simon Riggs <[email-masked]>
Date: Mon, 9 Jul 2012 12:19:28 +0100

On 9 July 2012 10:44, Dave Page <[email-masked]> wrote:

> exact same discussion before.

That highlights a key flaw.

If we distribute RPMs then the SRPMs should exactly match. If they
don't, that's a pretty serious set of bugs we're introducing.

Can I suggest that the process be changed? Push the SRPM code, then
generate RPMs from the released SRPM code. That way there is no
opportunity to forget anything. This is a substantial security
concern, not just a forgotten task.

Perhaps it would be useful to have a "build farm" that builds the RPMs
from SRPMs automatically, then we will have no need for manually
updating the RPMs at all. (And I mean build all binaries from publicly
available build scripts).

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 12:21:52 +0100

> available build scripts).

We're not talking about RPMs here.

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 9 Jul 2012 13:24:32 +0200

> We're not talking about RPMs here.

FWIW, the RPMs already do this, I believe.

---

From: Simon Riggs <[email-masked]>
Date: Mon, 9 Jul 2012 12:25:33 +0100

> We're not talking about RPMs here.

I am discussing the relationship of SRPMs and RPMs, which is a valid
point on this thread given the point that the RPMs and SRPMs have been
mismatched for some time and that the current process calls for manual
rather than automatic synchronisation.

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 12:28:33 +0100

> rather than automatic synchronisation.

I have no idea if that is true for the RPMs - as I said, we haven't
been discussing them.

---

From: Devrim GÜNDÜZ <[email-masked]>
Date: Mon, 09 Jul 2012 14:31:26 +0300

Hi Simon,

> rather than automatic synchronisation. 

Which SRPMs are you talking about? Community SRPMs? If so, they have
been always available on the website. If you are talking about OpenSCG
RPMs, that is a different thing.
-- 
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

---

From: Simon Riggs <[email-masked]>
Date: Mon, 9 Jul 2012 12:41:50 +0100

> RPMs, that is a different thing.

My words were a little unclear all round, please accept my apologies.

IMHO we should only list binaries on the postgresql.org website if
they are derived from build information that is owned by the PGDG, or
at very least publicly available at the time of the build and likely
to remain so afterwards. That process should be automatic as far as
possible, to minimise error, since the number of users of those
binaries is now very large.

Unverifiable binaries are a quality and security risk to the project.

Companies are welcome to provide value-added binaries to their
customers if they choose to do so but that should be a private matter.

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 13:05:54 +0100

> binaries is now very large.

Right - that's more or less what's been discussed and agreed. The
issue with the installers that Magnus raised, is that at present I
manually push the canonical GIT repo to git.postgresql.org, and often
forget to do it until reminded. That was raised in response to my
comment that the OpenSCG build scripts are not currently public at all
as far as I could see, and should be if their work is to be listed on
postgresql.org's primary downloads page.

> Unverifiable binaries are a quality and security risk to the project.

In theory. In practice it seems unlikely anyone would ever take the
time and energy to build them themselves and actually verify them -
the effort to do so would be huge (for example, assembling the 9.2
build machine for the installers and building all the necessary
dependencies for all the supported platforms etc. has so far taken a
number of man weeks). To verify the binaries we put out, someone would
have to build an exact mirror of that environment. That's not to say
it shouldn't be possible of course. In fact, it wouldn't even be
possible, as we digitally sign some of the executables to appease
Windows, and we obviously cannot share that certificate.

---

From: Devrim GÜNDÜZ <[email-masked]>
Date: Mon, 09 Jul 2012 15:10:15 +0300

Hi

On Mon, 2012-07-09 at 12:41 +0100, Simon Riggs wrote:

> to remain so afterwards.

I agree with this.

> That process should be automatic as far as possible, to minimise
> error, since the number of users of those binaries is now very large.

*Community RPMs* are more or less automated: There are some steps that
has to be done manually: Updating spec files, signing RPMs, performing
QA and then pushing to the repositories. Currently, when we build an
RPM, it passes through 3 separate tubes until it reaches final position.
We do the QA on first two tubes, since the last rsync is just a mirror
of the staging repository.

> Unverifiable binaries are a quality and security risk to the project.

Agreed -- and that is what me, Dave, etc., also think.

Regards,

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 9 Jul 2012 14:10:18 +0200

> postgresql.org's primary downloads page.

FWIW, the listing they have *now* is cleraly under "third party
distributions", so I don't think there's a problem with that one. It
also holds bitnami stuff. The point here is the *primary* download
pages (i'll make that plural since it was broken up a bit extra
lately).

> Windows, and we obviously cannot share that certificate.

It should be possible, and it's a much smaller (though not necessarily
small) effort if you only want to verify *one* version on *one*
platform with *one* subset of modules.

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 13:17:36 +0100

> platform with *one* subset of modules.

Putting aside the signed binaries, which clearly cannot be reproduced
bit-perfect, it's really not that much smaller - versions don't matter
that much as we use the same env for each major version, and most
packages are dependent on the server build, which requires the
majority of dependencies. The only real time saver would be to only
try to reproduce a subset of the supported platforms.

---

From: Scott Mead <[email-masked]>
Date: Mon, 9 Jul 2012 10:30:12 -0400

> Absolutely, I'm boarding a flight now, but will work on it once I hit
PFA a patch for the linux download pages

--Scottie

---

From: Simon Riggs <[email-masked]>
Date: Mon, 9 Jul 2012 15:50:22 +0100

> postgresql.org's primary downloads page.

It's not more or less. What you have said is not the same thing as I
have requested.

If it was done as I suggest, when you forget a step in the process
then the process would fail.

If you build from the public repo then you simply can't forget.

> Windows, and we obviously cannot share that certificate.

I know multiple users (aside from 2ndQuadrant) that re-build their own
binaries as a safety barrier in their release process, so I don't
believe the effort level is that high, nor do I believe people won't
do it. I take your point that it is maybe only 1% of people, but those
are the ones that report all the bugs.

The most important thing is that people can see the ingredients before
they eat the food.

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 16:02:35 +0100

> If you build from the public repo then you simply can't forget.

The security issue you quote is precisely why we built from the
canonical source, and not a secondary mirror.

You also wouldn't see a failure as you suggest - you'd probably see a
successful build that you later discover is missing recent bug fixes.

> are the ones that report all the bugs.

Well if you believe it's that easy, then I'd suggest you try for
yourself. Building the installers is *not* trivial, and building the
installers with an identical dependency tree to verify everything
we've built is a huge undertaking - and as I mentioned, not actually
possible on Windows because you would have no way to sign the binaries
you create with our certificate.

Note again though that we're talking *installers* here, and not RPMs
or other types of packages. The installers are *very* different from
other packages because we have to build so many of the dependencies
ourselves to ensure they'll run successfully on all the supported
platforms.

> The most important thing is that people can see the ingredients before

You're welcome to see the code - it's on git.postgresql.org. But that
doesn't mean it would be easy to build a bit-level verifiable copy of
our binaries.

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 17:14:04 +0100

> clearly it wasn't on your list earlier, even though I thought it was.

After much arguing with ssh, this is now automated, and pushing every
5 minutes to git.postgresql.org. The CFP reminder also went out as you
probably noticed.

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 9 Jul 2012 18:14:56 +0200

> 5 minutes to git.postgresql.org. The CFP reminder also went out as you

Yup, thanks.

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 9 Jul 2012 13:47:54 -0400

> other tasks I have on my plate.

I believe the significant point is that should Dave, EnterpriseDB, etc.
disappear tomorrow, the community _must_ have the instructions available
to continue producing binary releases.  "Asking for updated
instructions" is obviously impossible if those people/entities
disappear, so having current instructions always publicly available is a
requirement.

My point is that this not something that gets mixed in with other things
someone does for the community --- it is a requirement, and if it can't
be guaranteed, the community needs to rethink these binaries.  I am fine
with people forgetting stuff, but when someone says it is on my list of
other things I do --- that is unacceptable.

As I understand it now, the system is automated so the instructions will
always be current, right?  Are there any other "primary"
(non-thrird-party) downloads on our website that don't have current
build instructions?

-- 
  Bruce Momjian  <[email-masked]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 9 Jul 2012 13:53:59 -0400

> They are designed for production server installation where a GUI is not
> available and consistency across multiple distributions is a
> requirement.

What installers require a GUI?  I thought the EnterpriseDB installers
have a no-gui option?  Do you mean they include no GUI binaries like
PGAdmin?

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 18:54:21 +0100

> (non-thrird-party) downloads on our website that don't have current

Pretty much all of them I believe. I *think* Devrim has documented the
RPM build process, but I've never seen anything for Debian/Ubuntu, or
FreeBSD or Solaris etc. Of course, some of them are built in the same
way as any other package on their platform which makes them somewhat
easier to deal with.

---

From: Dave Page <[email-masked]>
Date: Mon, 9 Jul 2012 18:55:43 +0100

On Mon, Jul 9, 2012 at 6:53 PM, Bruce Momjian <[email-masked]> wrote:
> have a no-gui option?

They do. They have silent and command line modes, and can be
controlled interactively in the shell or GUI, from the command line,
or using response files.

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 9 Jul 2012 14:23:00 -0400

> way as any other package on their platform which makes them somewhat

Agreed.  Someday we might want to actually test to see that these can be
built by a new person, but that seems overkill at this point.

---

From: Simon Riggs <[email-masked]>
Date: Tue, 10 Jul 2012 10:16:46 +0100

+1

---

From: Scott Mead <[email-masked]>
Date: Tue, 10 Jul 2012 10:25:26 -0400

> have a no-gui option?  Do you mean they include no GUI binaries like

Two things specifically:

  1) A no-gui option
    The bitrock installers do have this, but at times, the technology isn't
perfect.  Many times, people want to just run a command and have it
install.  The idea with an RPM of these binaries is that we get the benefit
of the same binaries across installers, AND lower the barrier to entry by
making rpm -ivh ... just work.

  2) no GUI binaries
     This package is a 'server-only' install.  Same binaries, smaller
download size, quick and simple install / start / up and running.

--Scottie

---

From: Scott Mead <[email-masked]>
Date: Tue, 10 Jul 2012 10:26:10 -0400

> PFA a patch for the linux download pages

Any feedback on these pages?

--Scott

---

From: Dave Page <[email-masked]>
Date: Tue, 10 Jul 2012 15:39:54 +0100

On Tue, Jul 10, 2012 at 3:25 PM, Scott Mead <[email-masked]> wrote:
> perfect.  Many times, people want to just run a command and have it install.
> The idea with an RPM of these binaries is that we get the benefit of the
> same binaries across installers, AND lower the barrier to entry by making
> rpm -ivh ... just work.

No technology is perfect, but we have numerous users utilising text,
silent and response file installations quite successfully, including
all the additional post-copy steps the installers undertake. We also
have an unpack mode which is much more like an RPM install in that it
just lays down the binaries. Simply put, you can just run a command
and have it install.

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 10 Jul 2012 10:47:21 -0400

> just lays down the binaries. Simply put, you can just run a command

Agreed.  If the non-GUI mode of the Bitrock installers is broken, please
report it and let's fix it.  If it can't be fixed, maybe we need to use
another installer, but it is not clear what is broken.  Are you saying
it is better for non-GUI installs because they don't need to supply a
flag for non-GUI mode?  Shouldn't we just document the flag better?

The smaller download does make sense --- it is a leaner install.

I wonder if the OpenSCG text should more clearly state is doesn't
include any GUI componients.

---

From: Magnus Hagander <[email-masked]>
Date: Tue, 10 Jul 2012 16:57:54 +0200

> download size, quick and simple install / start / up and running.

So it's the binaries that come out of the EnterpriseDB installers? In
that case, it should at the very least reproduce the warnings we have
about those not integrating with the local packaging system (which I
realize *is* the point of them, but that should be stated more
clearly).

And I still don't really understand why you'd *want* this over the EDB
installers, but that's being discussed elsewhere in the thread, so I'm
not going to restart it here.

---

From: Scott Mead <[email-masked]>
Date: Tue, 10 Jul 2012 11:45:37 -0400

On Tue, Jul 10, 2012 at 10:47 AM, Bruce Momjian <[email-masked]> wrote:

> install.

Sorry I'm not being clear here (I've switched timezones just yesterday ).
I'm not saying that it's broken, just that, from a 'barriers' perspective,
many customers end up building their own server-only RPM.  They need
something that is consistent across the many disparate linux distro's (and
even just versions of the same distro) that they are running.

Some people do it to distribute through their own repository, some just
don't want to stay beholden to the linux distro's themselves.  Others just
need a consistent directory structure across distributions so that their
teams have one less thing to worry about.  The community yum repository and
binaries are a great thing, and in shops where linux the distributions are
consistent and version-ing is well managed, I would recommend them every
time.  The generic RPM option let's us fill a gap between the two; when it
comes to Small-Mid enterprise, it's very hard to stay consistent across all
distributions all the time while still making budget and timelines.  The
generic RPM/DEB allows for that middle-ground and lowers barriers in
mid-sized enterprises that haven't completely gotten their head around all
the different aspects of internal distribution.

> include any GUI componients.

Patch attached.

---

From: Magnus Hagander <[email-masked]>
Date: Wed, 11 Jul 2012 14:46:12 +0200

>> include any GUI componients.

I noticed two quick things: according to the page, you provide RPMs
for RedHat and SuSE (per the logos - I assume Fedora is included in
the RedHat part), and DEBs for Ubuntu.

Why do the patches suggest adding it to Debian (not listed) and to "other"?

I also for the first time clicked one of those links. To me, the way
that those pages request a login and registratoin to download them is
completely unacceptable. Yes, I realize there is a "there's a download
link at the bottom if you don't want to" (or as you like to phrase it,
"feel anti-social", which is clearly designed to make people sign up).
But I don't think that's acceptable for something to be listed on our
primary download pages. I'm ok (but not with a big margin) with how
EnterpriseDB does it - which is that they deliver your download and
*then* suggest you register as well. (Actually, I see now that they
have stopped doing that completely and instead throw some marketing
and ads for their cloud product at you)

I'd like to see that fixed for the developer bundles as well.
-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

---

From: Scott Mead <[email-masked]>
Date: Thu, 12 Jul 2012 15:46:28 -0400

On Wed, Jul 11, 2012 at 8:46 AM, Magnus Hagander <[email-masked]>wrote:

> >> > >     The bitrock installers do have this, but at times, the
> technology
> >> > > isn't

I'll update our site and get back to you.

> and ads for their cloud product at you)

Okay, we'll talk about this internally, but I'm thinking that we'll
probably kick the download off and then leave a register page up underneath.

--Scottie

--

---

From: Scott Mead <[email-masked]>
Date: Fri, 3 Aug 2012 16:08:18 -0400

On Thu, Jul 12, 2012 at 3:46 PM, Scott Mead <[email-masked]> wrote:

>> >> > > The idea with an RPM of these binaries is that we get the benefit
>> of
>> >> > > the

It took a while, but we updated the downloads that are launched from:
http://www.openscg.com/se/postgresql/packages.jsp

Once you drill into a platform, it will launch the download, and leave the
registration page up underneath.

--Scott

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 3 Aug 2012 16:24:34 -0400

> registration page up underneath.

I just clicked on:

	http://www.openscg.com/se/oscg_download.jsp?file=packages/postgres_9.1.4-1.i386.openscg.deb&user=

and my download did _not_ start automatically.  The "click here" link
does work.

---

From: Scott Mead <[email-masked]>
Date: Fri, 3 Aug 2012 17:14:30 -0400

> and my download did _not_ start automatically.  The "click here" link

Eek, missed a comment!

  All fixed now, thanks Bruce.

--Scott

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 3 Aug 2012 18:23:37 -0400

>   All fixed now, thanks Bruce.

I can confirm it worked.

---

From: Scott Mead <[email-masked]>
Date: Mon, 6 Aug 2012 15:06:21 -0400

> >   All fixed now, thanks Bruce.

Magnus, Any thoughts?

---

From: Magnus Hagander <[email-masked]>
Date: Fri, 10 Aug 2012 12:33:34 +0200

Hi!

Sorry for the delay - I was away for 3 weeks of vacatoin, and have
been working my way through the email backlog.

Those download pages look fine to me, and I'll work on integrating the
links to the download site today.

Thanks for dealing with our complaints :)