Subject: We should not transition to apt.postgresql.org until we have a PPA

From: Josh Berkus <[email-masked]>
Date: Wed, 13 Feb 2013 15:05:02 -0800

Folks,

I was just setting up a new PostgreSQL ubuntu server, and was kind of
stunned by the unnecessary complexity of the install instructions at
http://www.postgresql.org/download/linux/ubuntu/.  Also, they don't work.

If we're going to move our users to apt.postgresql.org, we really need
to provide a PPA for easy install.  Until we do that, we shouldn't
deprecate Martin's backports, which are easy to install and well-maintained.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

-- 
Sent via pgsql-www mailing list ([email-masked])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

---

From: "Joshua D. Drake" <[email-masked]>
Date: Wed, 13 Feb 2013 15:26:00 -0800

> deprecate Martin's backports, which are easy to install and well-maintained.

I just looked at this and I have to agree with Josh. This is really 
quite... wow.

JD

-- 
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579

---

From: Tom Lane <[email-masked]>
Date: Wed, 13 Feb 2013 18:34:00 -0500

> deprecate Martin's backports, which are easy to install and well-maintained.

Uh ... why would we be "deprecating" Martin's packages at all?

			regards, tom lane

---

From: Josh Berkus <[email-masked]>
Date: Wed, 13 Feb 2013 15:40:22 -0800

> Uh ... why would we be "deprecating" Martin's packages at all?

If you access Martin's PPA today, you'll get a message that they're soon
being deprecated and you should switch to apt.postgresql.org.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

---

From: Magnus Hagander <[email-masked]>
Date: Thu, 14 Feb 2013 06:20:23 +0100

> http://www.postgresql.org/download/linux/ubuntu/.  Also, they don't work.

Worst bug report ever? I really would think you knew better...

*what* does not work?

> to provide a PPA for easy install.

Why? You keep claiming that a certain product is needed in different
scenarios. If that was actually true in most cases, no progress would've
been made on the postgres project at all in the past 5 years at least.

Now, I can agree the process needs to be improved. But requiring a specific
product is not the way - why don't you actually tell us what the *problem*
is, so that the proper solution can be given, regardless of what product is
used?

That said, I believe Christophe has on his to do list to set up a
"repository package" to simplify installation. Kind of the same way it
works for the yum repository. We do not agree on the priority and the
importance of that (and for the record, I'm on your side here thinking it's
really important), but iirc we did agree on that being the most way
forward. I don't know if he's started the work in it yet though.

/Magnus

---

From: Magnus Hagander <[email-masked]>
Date: Thu, 14 Feb 2013 06:22:28 +0100

> Uh ... why would we be "deprecating" Martin's packages at all?

Just to be clear:

Martin is a part of the "we" that does the deprecation.

And we're not deprecating his packages. We are only deprecating the ppa
through which they were distributed, in favor of a different channel.
(which also brings other things)

/Magnus

---

From: Martin Pitt <[email-masked]>
Date: Thu, 14 Feb 2013 06:55:10 +0100

> Uh ... why would we be "deprecating" Martin's packages at all?

We currently have my backports PPA, Christophs pgapt.debian.net, and
apt.postgresql.org. It seems to me that of all three,
apt.postgresql.org is both the most complete (as it also has many
extensions) and also safer in the sense that it only publishes
packages after they passed the whole p-common test suite. While I run
the latter for the development release uploads, I don't run them on
all backports.

Installing the GPG key is unfortunately a separate step from

  sudo add-apt-repository 'deb http://apt.postgresql.org/pub/repos/apt/ precise-pgdg main'

as this cannot currently determine the GPG ID. It would be possible to
to so by downloading Release and looking at which key ID it is signed
with, but it's not currently done.

The bit that I don't quite like, and I quickly discussed that with
Christoph on FOSDEM, is the requirement of apt pinning. I'd much
rather drop the "NotAutomatic: yes" and the explicit pinning, so that
the repo will be used when you add it (as usually that's what you
want, after all?) People who don't want all packages there can still
configure pinning, but the current "all or nothing" instructions don't
do that anyway.

Either way, for the time being I still keep the PPA, I just want to
start pointing people at apt.postgresql.org. I'll at least keep the
10.04 LTS and 11.10 packages until the EOL of their respective distro
releases, to avoid breaking existing installs. But from 14.04 LTS
onward I'd like to fully switch to apt.pg.o, i. e. I will not include
any newer Ubuntu release into the PPA any more.

Thanks,

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

---

From: "Joshua D. Drake" <[email-masked]>
Date: Wed, 13 Feb 2013 22:21:40 -0800

On 02/13/2013 09:20 PM, Magnus Hagander wrote:
>
> On Feb 14, 2013 12:05 AM, "Josh Berkus" <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >
>  > Folks,
>  >

It all works. The problem is, the number of steps in comparison to just 
having a PPA.

>
>  > If we're going to move our users to apt.postgresql.org
> <http://apt.postgresql.org>, we really need

Because it is what is expected by Ubuntu users.

When you want custom packages from a custom repo, you install a PPA. 
When you want KDE 4.10 for precise you type KDE 4.10 precise PPA into 
google.

JD

---

From: Magnus Hagander <[email-masked]>
Date: Thu, 14 Feb 2013 08:36:11 +0100

having a PPA.

(the other) Josh specifically said it *also* does not work. It's the also I
was asking about.

/Magnus

---

From: Christoph Berg <[email-masked]>
Date: Thu, 14 Feb 2013 10:29:40 +0100

Re: Martin Pitt 2013-02-14 <[email-masked]>
> the latter for the development release uploads, I don't run them on

Fwiw, pgapt.debian.net is just an rsync copy of apt.postgresql.org
that I'll shutdown RSN, so it's really only two repos. (Martin and I
should probably send out a common announcement about the
deprecations.)

> configure pinning, but the current "all or nothing" instructions don't

I see the point. The behavior is in line with backport.debian.org's
"principle of least surprise", i.e. you will only get upgraded to
these packages if you explicitely ask for it. For Ubuntu PPA users the
expectation might be the other way round ("I configured the repo, so
please take over my system") - I'm not sure which way is the better
one to default to.

Christoph
-- 
[email-masked] | http://www.df7cb.de/

---

From: Christoph Berg <[email-masked]>
Date: Thu, 14 Feb 2013 10:35:14 +0100

Re: Magnus Hagander 2013-02-14 <CABUevEyhpv1O=sFX-JgFG57AV=[email-masked]>
> > to provide a PPA for easy install.

Maybe we just need to mention "PPA" on the wiki page so google finds
it?

> forward. I don't know if he's started the work in it yet though.

It's kind of an chicken-and-egg problem, if you download the repo
package, you still don't have any key to verify it. Though "wget
pgdg.deb && dpkg -i pgdg.deb" will probably be trustworthy enough for
most people so we should be providing that, yes.

Christoph

-- 
Sent via pgsql-pkg-debian mailing list ([email-masked])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-pkg-debian

---

From: Martin Pitt <[email-masked]>
Date: Thu, 14 Feb 2013 10:42:17 +0100

Christoph Berg [2013-02-14 10:35 +0100]:
> package, you still don't have any key to verify it.

That's true. We might ship the key in postgresql-common itself then,
and add a script to install the backports package? For existing stable
releases we can point people to the install instructions.

Martin

---

From: Martin Pitt <[email-masked]>
Date: Thu, 14 Feb 2013 10:44:16 +0100

> please take over my system") - I'm not sure which way is the better

Debian/Ubuntu backports potentially affect the whole system, so almost
every user will only want to pick a package or two, not all of them.
Also, the point of those "NotAutomatic" flag was that you can even add
the apt source by default everywhere.

Most PPAs, as well as apt.pg.org are "topic" repositories which IMHO you
would usually enable because you want to use them.

Martin

---

From: Christoph Berg <[email-masked]>
Date: Thu, 14 Feb 2013 13:26:43 +0100

Re: Martin Pitt 2013-02-14 <[email-masked]>
> releases we can point people to the install instructions.

Ooooh, that's a brilliant idea! (vs. a separate package)

It would even make the existing pgdg-keyring package redundant.

Re: Martin Pitt 2013-02-14 <[email-masked]>
> would usually enable because you want to use them.

Well I'd tend to say we have so many packages in there that we are
somewhere inbetween.

But with your "ship in postgresql-common" idea, we can have an
installer script that will take care of all steps and make the wiki
instructions very simple.

Christoph

---

From: Josh Berkus <[email-masked]>
Date: Thu, 14 Feb 2013 10:35:04 -0800

Folks,

(1) Issue with instructions on Ubuntu 12.04

1. install the key using the wget command.

2. there is no pgdg.list file to edit, per instructions.  Nor, for that
matter, is there a pgdg.pref file.  If the instructions mean *create*
these files from scratch, they should say that.

===========

(2) Problem with general process

The instructions expressed on the page involve 6 steps, three of which
require editing text files with persnickety syntax, thus requiring an
intimate knowledge of Debian packaging, and mapping your numerical
release number to the "cute" release names, and rearranging lines of a
large complex system-generated file, and messing with repository keys.

Frankly, installing PostgreSQL from source will be easier than following
those instructions.  It represents a return to "PostgreSQL is hard to
install" for Ubuntu users.

Compare this to the simple and largely infallable sequence for
installing the PPA:

1. apt-get install python-software-properties
2. add-apt-repository ppa:pitti/postgresql
3. apt-get update
4. apt-get install postgresql-9.2

That's *it*.  No text files to edit, no keys to mess with, no finicky
syntax to learn.  Just four commands which can be put in a simple shell
script and deployed across a dozen servers, thanks to Martin's good work.

The new process represents a 20X increase in sysadmin time to install
PostgreSQL on a server.  This will result in less PostgresQL
installations.  Do we really want that?

Alternately, Martin, this will mean (for our professional clients)
switching from Ubuntu to Red Hat/Fedora, just because it's easier to
maintain PostgreSQL there.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

---

From: "Joshua D. Drake" <[email-masked]>
Date: Thu, 14 Feb 2013 11:01:37 -0800

> 1. install the key using the wget command.

Well this isn't that uncommon but I do see your point.

> maintain PostgreSQL there.

That's a bit alarmist, slow down on the coffee. I agree that 
apt.postgresql.org should work as a simple PPA but I guarantee you that 
our "professional clients" are not going to switch from Ubuntu to Red 
Hat/Fedora, that's ridiculous.

It will however make them wonder what .org is smoking and if they should 
just stay with the latest stable release until we get our act together.

JD

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Thu, 14 Feb 2013 21:51:45 +0100

> 1. install the key using the wget command.

and that is a problem?

> these files from scratch, they should say that.

"edit" in my interpretation of the phrasing there includes creating the
file - if you have a better wording to suggest please provide a patch...

not sure what the "intimitate knowledge requirement" here is - pasting
exactly the strings proposed is enough and there is not a single
requirement on understanding debian packaging, though i have to admit
that NOT understanding it is kinda a sign that you should not have root
on the debian based box you are on and you are an admin for.

> install" for Ubuntu users.

I very much doubt that - because just for a starter getting all the
build requirements on a typical ubuntu box in place is way more complex
than following the very trival steps on the above mentioned docs

> 4. apt-get install postgresql-9.2

I completely fail to see how that is fundamentally different from the
docs that we have now (not saying they cannot be improved) - once you
have decided that an external package source is ok, the actual 30s or
45s you need to invest to make that true does not matter at all.

> installations.  Do we really want that?

I really think you need to step back a bit - editing a textfile or two
vs typing a few lines on the commandline is hardly a 20x increase in
sysadmin time. And even if it would be 5s(ppa) vs 100s(what we have now)
for the first install that is not even measurable noise in any deployment.

> maintain PostgreSQL there.

so a hypothetical 5s vs 100s issue combined with the fact that 'not
understanding how the packaging system on the OS I rely on and that I
have deployed on "dozends of servers" works' will make them switch their
entire platform to a different distribution?

Stefan

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 15 Feb 2013 20:38:54 -0500

> on the debian based box you are on and you are an admin for.

I don't think "codename" is really good wording here:

	Edit the file /etc/apt/sources.list.d/pgdg.list, and add a line for the
	repository, substituting the proper "codename" for your release deb

		http://apt.postgresql.org/pub/repos/apt/ precise-pgdg main

Shouldn't we highlight where that name goes?  I am running Squeeze and
though I know "precise" is a code-name, I found out only by accident.  I
particularly think users will not recognize codenames of Debian release
newer than their own.  I suggest this wording:

	Edit the file /etc/apt/sources.list.d/pgdg.list, and add a line for the
	repository, substituting the proper Debian release name:

		http://apt.postgresql.org/pub/repos/apt/ <i>release-name</i>-pgdg main

Also, we should tell users how to find their release name.  I looked on
Debian and I can't even find out how to find the name, though I know it
is Squeeze.

I am using Ubuntu 12.04 on my laptop and I don't know the release name
of that, nor do I know how to find it.

Also, can't we change this to use a shell?

	Package: *
	Pin: release o=apt.postgresql.org
	Pin-Priority: 500 

as in:

	sudo cat > /etc/apt/preferences.d/pgdg.pref <<END
	Package: *
	Pin: release o=apt.postgresql.org
	Pin-Priority: 500 
	END

That avoids requiring them to start an editor as root, which we don't
even mention.

Folks, we shouldn't be requiring decoder rings here to install Postgres
--- we have to do better.

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

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

---

From: Christoph Berg <[email-masked]>
Date: Sat, 16 Feb 2013 09:44:22 +0100

Re: Bruce Momjian 2013-02-16 <[email-masked]>
> I don't think "codename" is really good wording here:

That's the official Debian/Ubuntu term, though we can certainly use
something else if it makes things easier for users.

> 		http://apt.postgresql.org/pub/repos/apt/ <i>release-name</i>-pgdg main

The instructions on the wiki page make this more clear:

 Edit /etc/apt/sources.list.d/pgdg.list. The distributions are called
 codename-pgdg. In the example, replace squeeze with the actual
 distribution you are using:

 deb http://apt.postgresql.org/pub/repos/apt/ squeeze-pgdg main

and "squeeze" is in italics there. I'll look into merging the texts to
a common version.

> 	Pin: release o=apt.postgresql.org

"Write this to disk as root" is suprisingly hard in shell. Your
example misses quoting, the best variant I know is

	sudo tee -a /etc/apt/preferences.d/pgdg.pref <<END

which isn't very nice to look at either (and prints back stuff on
stdout).

I'm starting to think that the best version would be to have people
wget a shell script and execute that, but that's 100% evil from a
security perspective. (We will include such a script in the
postgresql-common package so if you have a recent enough install from
your vendor, you can use that, but this will not make it into
Debian/Ubuntu until the second-next releases.)

> --- we have to do better.

I don't get this, Do you mean the pgdg-keyring package?

Christoph

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 16 Feb 2013 10:33:09 -0500

> something else if it makes things easier for users.

OK.  How do people find their codename?

> and "squeeze" is in italics there. I'll look into merging the texts to

Yes, that is much better.

> example misses quoting, the best variant I know is

Oh, yes, my bad.  You are right about it being tricky.  I was unclear if
were wanting to append or replace.  If they run this twice, it would be
good if they don't get two copies of the text in that file.  Maybe:

     sudo sh -c "cat > /etc/apt/preferences.d/pgdg.pref <<END
     Package: *
     Pin: release o=apt.postgresql.org
     Pin-Priority: 500
     END"

> security perspective. (We will include such a script in the

Yes, evil.  I think people can copy/paste OK.

> I don't get this, Do you mean the pgdg-keyring package?

It was a joke, meaning we shouldn't require special knowledge for people
to get this installed, which this does require currently.

---

From: Bruce Momjian <[email-masked]>
Date: Sat, 16 Feb 2013 18:40:34 -0500

> OK.  How do people find their codename?

OK, I found the answer:

	$ lsb_release --short --codename
	squeeze

> > > 		http://apt.postgresql.org/pub/repos/apt/ precise-pgdg main

I suggest we use:

  http://apt.postgresql.org/pub/repos/apt/ `lsb_release --short --codename`-pgdg main

That way, it auto-detects the codename.  This works on Debian and Ubuntu.

---

From: Alvaro Herrera <[email-masked]>
Date: Sun, 17 Feb 2013 02:40:28 -0300

> 	$ lsb_release --short --codename

Uhm.

$ lsb_release
No LSB modules are available.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

---

From: Bruce Momjian <[email-masked]>
Date: Sun, 17 Feb 2013 07:17:45 -0500

> No LSB modules are available.

Uh, that's what I get too.  Try it with the arguments I suggested,
please.

---

From: Kevin Grittner <[email-masked]>
Date: Sun, 17 Feb 2013 07:26:53 -0800 (PST)

$ lsb_release
quantal

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

---

From: Alvaro Herrera <[email-masked]>
Date: Sun, 17 Feb 2013 23:08:25 -0300

> Uh, that's what I get too.  Try it with the arguments I suggested,

Oh, what a weird program.  Yes, I get "wheezy" with your suggested
options.

---

From: Christoph Berg <[email-masked]>
Date: Mon, 18 Feb 2013 09:25:15 +0100

Re: Bruce Momjian 2013-02-17 <[email-masked]>
> That way, it auto-detects the codename.  This works on Debian and Ubuntu.

Well the original version had the advantage that it was
copy-and-paste-able at least for Debian squeeze users.

The Ubuntu PPA pages have nifty js stuff for that. Go to
https://launchpad.net/~pitti/+archive/postgresql, expand "Technical
details about this PPA", and watch the dropdown box magic. We should
have that too :)

Christoph

---

From: Dave Page <[email-masked]>
Date: Mon, 18 Feb 2013 09:15:59 +0000

> --- we have to do better.

Agreed. A number of years back we did a lot of work to make it easy
for people to download and install PostgreSQL, through redesigns  of
the download pages and intentionally directing less technical users to
the easiest ways to get up and running with everything they need to
get started (the one-click installers). That was redesigned a few
months back to point less technical users at the RPM/DEB packages
instead, as it was felt that with the right wording and stabilisation
of the package repos that could be made as easy as the installers.
This is a major step backwards, and needs to be fixed ASAP.

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

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

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 18 Feb 2013 09:29:19 -0500

> copy-and-paste-able at least for Debian squeeze users.

Uh, that is copy-and-paste-able for any Linux user, no?

Should I submit a web patch for all of this?

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 18 Feb 2013 10:42:35 -0500

> Should I submit a web patch for all of this?

Oh, I see now --- that is a line that that has to go into
/etc/apt/sources.list.d/pgdg.list:

	deb http://apt.postgresql.org/pub/repos/apt/ precise-pgdg main

I guess we could append it to the file, but that would mean users
shouldn't run the script multiple times, which is bad.  I guess we just
need to tell users the command to find their codename.

---

From: Andres Freund <[email-masked]>
Date: Mon, 18 Feb 2013 17:12:58 +0100

> This is a major step backwards, and needs to be fixed ASAP.

Describing any of the installer packages on debian based distros as
easier as the .deb's imo is not really matching reality in the
least. And it too often results in angry users reporting bugs because
they didn't update.

The instructions sure could be better, but this thread seems to be going
*way* overboard. Just about any user installing a postgres version thats
not provided by the distribution will have added additional repositories
before.

Greetings,

Andres Freund

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

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Mon, 18 Feb 2013 19:23:23 +0100

> This is a major step backwards, and needs to be fixed ASAP.

I heavily disagree - while there are certainly improvements to be made I
don't think what we have is a "major step backwards" - we now have stuff
we did not have before, like a much larger selection of packages for a
much larger number of distributions and like with every project we ever
did we will have to do incremental improvements.

I really really doubt that for anybody who is not able to use the
distribution provide packages the current instructions are a problem at
all and whatever we do the easiest way to get pg will always be the
package that the distribution has because that one is "perfectly"
integrated and available.

Comparing for example the current apt.postgresql.org instructions to
what we have for the rpm package we are imho on parity (like people
complain about it being hard to figure out what their current OS is -
you need to know that for rpms as well and afaik there has been no
complaints about that).

Stefan

---

From: Dave Page <[email-masked]>
Date: Mon, 18 Feb 2013 18:40:23 +0000

> integrated and available.

History has proven that wasn't the case. We used to get regular emails
to webmaster@ from people who were confused about what combination of
packages they had to install because it simply wasn't clear, and like
it or not, there are a lot of people out there who are not familiar
with platform native packaging - including a significant percentage of
Oracle users for example.

> you need to know that for rpms as well and afaik there has been no

Seriously? This is from the download pages... Setting up yum.postgresql.org:

1) Choose the appropriate repo RPM from
http://yum.postgresql.org/repopackages.php

2) Install with a command like:

rpm -i http://yum.postgresql.org/9.1/redhat/rhel-6-x86_64/pgdg-redhat91-9.1-5.noarch.rpm

Compared to... Setting up apt.postgresql.org:

1) Import the repository signing key

wget -O - http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc | sudo
apt-key add -

2) Edit the file /etc/apt/sources.list.d/pgdg.list, and add a line for
the repository, substituting the proper "codename" for your release

3) Configure apt's package pinning to prefer the PGDG packages over
the standard ones in /etc/apt/preferences.d/pgdg.pref

Package: *

4) Update the package lists, and install the pgdg-keyring package to
automatically get repository key updates

sudo apt-get update
sudo apt-get install pgdg-keyring

They aren't even remotely on parity with each other!

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 18 Feb 2013 19:47:06 +0100

> Oracle users for example.

No, history definitely has not proven that. History has proven that
*what we had before* was confusing, that it definitely has. But just
because going from A to B is an improvement, doesn't mean that going
from B to C can't *also* be an improvement. It only proves that going
back to A would be.

I haven't seen a single email expressing that problem since we put the
new instructions online in July.

I have, however, seen fewer questions to me personally (going from
"not too many", to "exactly 0") from people who got installs confused
up. And I haven't had to help anybody fix up an install to get
libraries and whatnot to work properly with third party packages since
that went online.

Now - that was since the new instructions went online, using the old
PPA instructions. I don't have enough data since the
apt.postgresql.org part got in (mid december) to actually say if that
made it better or worse.

> Seriously? This is from the download pages... Setting up yum.postgresql.org:

<snip>

I definitely agree with this part though - we need to make the apt
instructions to be as easy as the RPM ones. And they are not today.

Whether it's just the instructions that should be improved, or the
technology, is a different question - but it's not as easy as the RPMs
today.

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

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 18 Feb 2013 19:51:49 +0100

> would usually enable because you want to use them.

+1 for this. Or, +100 if I'm allowed ;)

As I argued when we set this up, I think this is the 99% use-case. We
should default to this. It's always possible to change it for the
less-common usecase. I dropped the argument because I think it was
much more important to get *anything* out there than to get stuck on
this, and because I was told it was a but too non-debian:y. But if you
are also in agreement, maybe this is something that can be reopened
for discussion?

 I see two ways of doing this:

1) Just change the defaults per your suggestion above. This would
remove one step of the installation process completely. You're still
going to need to add the key manually per that.

2) Create a DEB package that works the same way as the RPM "repository
package". That means I download and install one DEB, and it sets up my
repository for me. It adds the line to apt.sources.d and it adds the
key. If we do this, it could potentially just set the pinning for us,
and the *repository* could still have the old defaults. The bottom
line is that the user would get what 99% of them want by default and
in a single step (actually, it would be two steps since DEB can't
install directly from http urls, but it would still be a huge
improvement - and it would work transparently if someone used a GUI
and just clicked the link).

What I would personally most like to see is the combination of these -
change the repository default to using "our packages" with priority,
*and* create a DEB wrapper package that sets it up for us
automatically.

---

From: Dave Page <[email-masked]>
Date: Mon, 18 Feb 2013 19:01:14 +0000

> from B to C can't *also* be an improvement. It only proves that going

That's not what I said. If I thought C couldn't be an improvement, I
would have objected to it. I don't and it can be. But right now, it's
a step backwards - it's convoluted and confusing.

> new instructions online in July.

I strongly believe that's because we currently have the distro
provided packages at the top of the list - and as we found before, the
people that have problems tend to only read the first option on the
list, and those instructions are now pretty straight forward.

---

From: Dave Page <[email-masked]>
Date: Mon, 18 Feb 2013 19:07:30 +0000

On Mon, Feb 18, 2013 at 4:12 PM, Andres Freund <[email-masked]> wrote:
> least.

Putting them first on the download list cut the regular queries about
"how do I install PostgreSQL" on the webmaster alias to zero
overnight. It was *clearly* easier for the less technical users.

> And it too often results in angry users reporting bugs because
> they didn't update.

I don't think I ever heard such a complaint.

> not provided by the distribution will have added additional repositories

Right - but it's not normally anything like so complex. See the Yum
instructions for example - and I'm not even sure they're as simple as
they could be (you could just click the link on some distros I
believe, and the package manager will offer to install the repo RPM).

I should also note that I'm *not* arguing that we should promote the
installers over the platform native packaging; I'm arguing - as one of
the few people that has had to deal with questions to webmaster@ from
people confused about installing in the past - that we should not
allow our installation instructions to become difficult or confusing
for novice users again.

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Mon, 18 Feb 2013 20:12:09 +0100

> rpm -i http://yum.postgresql.org/9.1/redhat/rhel-6-x86_64/pgdg-redhat91-9.1-5.noarch.rpm

well so far so good - BUT...

> Pin: release o=apt.postgresql.org

http://yum.postgresql.org/howtoyum.php clearly tells that the above is
necessary as well on redhat if you want to override the distribution
packages:

--
As root, cd /etc/yum.repos.d
Edit distro's .repo file:

    On Fedora, edit fedora.repo and fedora-updates.repo, [fedora] sections
    On CentOS, edit CentOS-Base.repo, [base] and [updates] sections.
    On Red Hat, edit edit /etc/yum/pluginconf.d/rhnplugin.conf [main]
section.

Add
exclude=postgresql*
--

so I still think they are equivalent...

Stefan

---

From: Josh Berkus <[email-masked]>
Date: Mon, 18 Feb 2013 12:07:25 -0800

Stefan,

---

From: Brendan Jurd <[email-masked]>
Date: Tue, 19 Feb 2013 07:14:25 +1100

This may be a daft question to ask at this point in the discussion,
but what does apt.postgresql.org buy us that a PPA doesn't?

If the concern is to have Debian/Ubuntu packaging that has an
"official" project flavour, as opposed to Martin's "personal" package
archive, why don't we just set up a "postgres" PPA or similar?

If it's important to have apt.postgresql.org for other reasons, then
maybe the "postgres" PPA could be built from apt.p.o?

I guess I just don't understand why in Zeus' beard we would move away
from the PPA arrangement.  It is super convenient, and as others have
pointed out, it's what Ubuntu users expect to do when they need
something to be more up-to-date than the standard distro package.  If
apt.p.o carried with it some enormous advantage then that would be
okay, but reading back through the thread I'm not sure anyone has
articulated such.

Cheers,
BJ

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Mon, 18 Feb 2013 21:32:55 +0100

On 02/18/2013 09:07 PM, Josh Berkus wrote:
> From the perspective of someone using Martin's PPA, it is a major step
> backwards.  The PPA had all of the packages I was interested in, and
> took 5% of the time to install per system as the new procedure does.
> 
> It may not be a step backwards for pure Debian, or for users on old/odd
> Ubuntu versions, but it *certainly* is for current Ubuntu.
> 
> You clearly haven't tried to follow both procedures from scratch, let
> alone tried to teach them to anyone else.

I did - running debian, ubuntu AND centos, the main difference is from
dealing with downrating the distribution versions compared to the pgdg ones.
I have not much experience teaching that stuff to others but that might
be because people find the instructions enough so I have never been
asked to explain them.

> 
> I'm being reminded of when I first joined OpenSolaris at Sun, and I
> complained that booting the system for the first time required editing
> several files using vi, with no alternate editor available, even vim.
> One of the Solaris engineers said "if you don't want to learn vi, you
> have no business running Solaris".  That sort of attitude is one of the
> major reasons Opensolaris never succeeded in expanding the market for
> Solaris.

which is imho not even closely comparable to the current instructions in
terms of complexity...

> 
> I will point out that some developers run Ubuntu and Debian on their
> desktops.  These folks are not Sysadmins.  Requiring them to have the
> knowledge to edit cryptic packaging files correctly, and look up the
> stupid Debian "codename", just means that they will not use a current
> version of PostgreSQL, and thus will be ignorant of our new features.
> Some of these developers will turn to Redis and Mongo instead, because
> those databases each have a 30-second installation procedure which
> requires no systems knowledge.

those developers will simply use whatever they default OS provides - and
frankly I think that for most people that is actually more sensible than
using -pgdg packages. Debian and Ubuntu have very good support for
postgresql...

> 
> We already got our clock cleaned by MySQL once upon a time because
> "PostgreSQL is too hard to install".  Let's not do it again.

quality first is the main argument here - the maintainer of the current
"oh its so wunderful" ppa setup itself says that the new system is
superior for erm (among others) "better QA".
I don't resist making our user experience better for installing stuff,
in fact I welcome it a _LOT_ but telling everybody that adding a string
to a file is a major hurdle does not help progress either...

Stefan

---

From: Andres Freund <[email-masked]>
Date: Mon, 18 Feb 2013 21:52:40 +0100

> but what does apt.postgresql.org buy us that a PPA doesn't?

The PPA:
- only supported a few versions of pg, not all supported ones
- regularly dropped releases while they were still supported by PGDG
- had quite a few packages only for certain versions (e.g. pgadmin)

All that is understandable, its a lot of work, but it really sucks if
you use pg productively and suddently no updates are available anymore
for the version youre using.

Greetings,

Andres Freund

---

From: Markus Wanner <[email-masked]>
Date: Mon, 18 Feb 2013 21:56:39 +0100

> archive, why don't we just set up a "postgres" PPA or similar?

Well, a PPA - by its very definition - is a personal package archive.
It's an Ubuntu/Launchpad thing. Not something a Debian user wants to use.

> maybe the "postgres" PPA could be built from apt.p.o?

You need to upload sources to build a PPA. Launchpad builds the binaries
(for x86 and amd64 exclusively, IIRC).

Thus, a self-hosted apt.postgresql.org clearly can serve more use cases
than a PPA does. And being closer to the Debian way of doing it
certainly doesn't hurt upstream acceptance (or that of other Debian
based distributions).

That being said, I'm all for simplifying the installation. Upthread,
Christoph and Martin already discussed viable approaches.

Regards

Markus Wanner

---

From: Greg Stark <[email-masked]>
Date: Mon, 18 Feb 2013 23:30:31 +0000

> Pin: release o=apt.postgresql.org

Why is this necessary? Is there a realistic chance Debian/Ubuntu will
suddenly leap-frog us and have more recent versions? Maybe our
packages should have a different name and be installable alongside the
stock packages?

> They aren't even remotely on parity with each other!

Can you articulate why you think they aren't? Aside from the step
above (which Josh actually points out you need to do on Yum as well)
they seem pretty much equivalent. One extra command to add gpg keys
doesn't seem like a watershed difference.

-- 
greg

---

From: Josh Berkus <[email-masked]>
Date: Mon, 18 Feb 2013 15:58:46 -0800

> doesn't seem like a watershed difference.

The below goes for both Yum and the PPAs:

1. you don't have to create or edit any configuration files
  - the editing Yum config file step mentioned is strictly optional, and
you can install postgresql without doing it.

2. you don't have to look up the mapping for Debian's "cute" version names.

3. you don't have to add and enable keys (which is two steps, actually)

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

---

From: Greg Stark <[email-masked]>
Date: Tue, 19 Feb 2013 00:22:40 +0000

> 2. you don't have to look up the mapping for Debian's "cute" version names.

Well the only reason that's true for Yum is that we only support one
version. If you want to use rhel-5 or rhel-7 or rhel on POWER6 you're
just out of luck. If we did you would have to make the same
substitution.

I don't actually have anything against PPA or providing a script which
actually adds the right thing automatically. i just don't understand
why people are saying the RPM instructions which seem exactly
equivalent are in any way better.

-- 
greg

---

From: Dimitri Fontaine <[email-masked]>
Date: Tue, 19 Feb 2013 10:26:39 +0100

Hi,

> allow our installation instructions to become difficult or confusing

The novice users will use the default provided PostgreSQL on their
distro. That's 8.4.13 for squeeze, and 9.1 everywhere else, currently,
in debian, and something not that different in ubuntu.

  http://packages.debian.org/search?keywords=postgresql
  http://packages.ubuntu.com/search?keywords=postgresql

The PGDG repository target audience is *not* novice users.

This service has been built for production users who know they want 9.2
on squeeze, or know they want to be able to upgrade from squeeze to
wheezy without having to upgrade from 8.4 to 9.1 at the very same time.

I think what we have now is really simple enough for those users, and as
Magnus I say that because a fair number of users are turning to me when
it's not simple enough, and they've stopped asking me any such questions
since we published the repository.

Now, I agree that when targetting the novice users out there, it could
be made simpler. Just let them install the default debian or ubuntu
provided version of PostgreSQL, you can not possibly provide simpler
installation than the OS provided one in those two ones. And when later
they realize the should know better, at this time the PGDG offer will
make about perfect sense for them.

Again, our target here is users who know they want 9.2 in squeeze and an
upgrade path to wheezy allowing them to stay on 9.2.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

---

From: Dimitri Fontaine <[email-masked]>
Date: Tue, 19 Feb 2013 10:41:29 +0100

> +1 for this. Or, +100 if I'm allowed ;)

FWIW, +1 too.

My preference is to just switch the default the other way round, and
provide advanced setup instructions only labelled as such.

---

From: Dimitri Fontaine <[email-masked]>
Date: Tue, 19 Feb 2013 10:42:45 +0100

> but what does apt.postgresql.org buy us that a PPA doesn't?

Upgrade paths.

I don't think you can easily upgrade ubuntu while staying with whatever
currently supported version of PostgreSQL you have in production (for
extra fun make it 9.0) at the time of the ubuntu upgrade.

Regards,

---

From: Dave Page <[email-masked]>
Date: Tue, 19 Feb 2013 09:44:24 +0000

> necessary as well on redhat if you want to override the distribution

Adding one line to a file doesn't make it equivalent - it's still a
more complex procedure. Further, that line is not required with a Yum
installation at all - the instructions on www.postgresql.org are
complete (and actually a little more complex than they need to be -
you don't need to use the command line at all in fact).

---

From: Dave Page <[email-masked]>
Date: Tue, 19 Feb 2013 09:53:25 +0000

> just out of luck. If we did you would have to make the same

Huh? It's true we don't support RHEL 7 (which isn't released yet) or
POWER, but we do support other variations.

> equivalent are in any way better.

yum.postgresql.org has a two step process to use - go to a webpage,
get the URL for the repo RPM for the platform you have and then run a
command to fetch and install it. That can actually be shortened to
"click the link and install the RPM using package manager when
prompted".

apt.postgresql.org has 4 steps at present, two of which involve
manually editing config files.

They may be roughly equivalent to most of us here in terms of the time
they will take, but they certainly are not equivalent to novice users
either in terms of effort, or perception.

---

From: Dave Page <[email-masked]>
Date: Tue, 19 Feb 2013 09:57:13 +0000

> The PGDG repository target audience is *not* novice users.

You're seriously suggesting that novice users (and by novice, we're
talking about operating system users, not necessarily database users)
should not be able to choose the version of PostgreSQL they run,
because we cannot be bothered to simplify the installation
instructions?

This sort of attitude is *exactly* why PostgreSQL has a reputation for
being hard to use and the community has a reputation for being
exclusive and unwelcoming to newcomers.

We should be doing everything we can to make it easy for new users,
whatever their background or experience level, to use PostgreSQL as
they wish.

---

From: Dimitri Fontaine <[email-masked]>
Date: Tue, 19 Feb 2013 11:02:34 +0100

> whatever their background or experience level, to use PostgreSQL as

I totally agree with that.

And the simplest we could do while being technically correct for
PostgreSQL major versionning support, extensions building, debian
integration, upgrade paths, automated package building, QA and automated
testing is what you know as apt.postgresql.org.

When you compare what we have now there to any other offering, please
remember to include an upgrade paths discussion.

It took years to build and we're far from done still. As Stefan best
said it in this thread, one step at a time.

Regards,

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 19 Feb 2013 07:03:04 -0500

> Oh, what a weird program.  Yes, I get "wheezy" with your suggested

Adding to this complexity, I just realized that the Ubuntu code names
are different from the Debian code names, even though Ubuntu is based on
Debian.  Fortunately "lsb_release --short --codename" works on both. 
While most Debian users probably know their code name, I doubt Ubuntu
users do.

Do we actually create different packages for Debian and Ubuntu?

---

From: Magnus Hagander <[email-masked]>
Date: Tue, 19 Feb 2013 13:04:04 +0100

> Do we actually create different packages for Debian and Ubuntu?

Yes, but that's just because the dependencies are different versions.
There is no functionality difference in our debian and ubuntu
packages.

---

From: Markus Wanner <[email-masked]>
Date: Tue, 19 Feb 2013 14:10:58 +0100

On 02/19/2013 01:03 PM, Bruce Momjian wrote:
> Debian.

Guys, this code name bashing is starting to get ridiculous. Some people
are better at remembering names, others are better at memorizing
numbers. So where's the big deal?

I myself firmly belong to the first group, having trouble remembering my
own phone number. That's why I barely have an idea of what Debian or
Ubuntu version *number* I'm using. But I know for certain that I'm
running squeeze (or wheezy, on more experimental machines or newish
hardware) and precise (and yes, I know it's an LTS version).

Of course, numbers have more intrinsic information. But what use is
knowing that 4 follows 3 if you don't remember whether you are on
version 3 or 4? (Not to mention numbering gaps, major vs. minor version
number increments, and similar marketing non-sense.)

For mates in my group: here's the command (of about equal complexity) to
find out your "release number":

  $lsb_release --short --release
  7.0

Regards

Markus Wanner

P.S.: did the Postgres project ever considering using proper release
names? That would avoid the recurring confusion between 9.4 and 10.0,
for example.  *runs* *hides* *covers* *prays*

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 19 Feb 2013 08:20:22 -0500

>   $lsb_release --short --release

My only point is that we assumed the user knew the release names to
install the software, and often they don't, and we didn't tell them how
to find out.

I have no problems with the use of code names.

---

From: Markus Wanner <[email-masked]>
Date: Tue, 19 Feb 2013 14:30:17 +0100

> install the software, and often they don't, and we didn't tell them how

Oh, okay. That's surprising me. It's the exact opposite of my
experience, though. My customers were usually talking about etch, lenny,
lucid, or precise. But well, maybe they just figured they need to
look-up the code name to be able to talk to me.  :-)

Markus Wanner

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 19 Feb 2013 08:44:31 -0500

> look-up the code name to be able to talk to me.  :-)

I have been running Ubuntu for 5 years and didn't know the code name of
my release until I had to track a bug report a few months ago.  In fact,
finding the Ubuntu version numbrer isn't obvious either --- you have to
look under Details in System Settings, i.e. uname -a does not show it to
you.

Also, when I asked how on this list how users are supposed to find their
code name, look at the fact I got no replies, had to find it myself via
a Google search, then others were confused by how to run the command
because the command without arguments isn't very useful.

---

From: Markus Wanner <[email-masked]>
Date: Tue, 19 Feb 2013 14:53:25 +0100

> because the command without arguments isn't very useful.

Well, that may also indicate that most others know their code name and
didn't ever have to look it up. I certainly couldn't have told you about
lsb_release. If I'm not sure, I usually check /etc/apt/sources.list,
because that's what I'm editing for upgrades.

Regards

Markus Wanner

---

From: Greg Smith <[email-masked]>
Date: Tue, 19 Feb 2013 10:07:24 -0500

> Debian.  Fortunately "lsb_release --short --codename" works on both.

I'm using to seeing the short option version of this as "lsb_release 
-cs" instead.  Being able to tell Debian from Ubuntu is one of the 
points of lsb_release.  Note that lsb_release works on RHEL/RPM systems, 
too, but good naming there doesn't go back as far.  RHEL6 is codename 
"Carbon",  but RHEL5 was "Final".

The amount of hysterics relative to forward progress in this discussion 
has been a bit high.  A few observations:

-The PPA mechanism is strongly associated with Ubuntu.  An official PPA 
published by postgresql.org would be useful as a replacement for 
ppa:pitti/postgresql

-There are ways to hack a PPA onto a Debian system.  But they're that, 
hacks, and you will never get many skilled Debian administrators to use 
one for defensible reasons.  The apt repo vs. PPA flame war is large, 
political, and best avoided; it can't be resolved here.  Using a PPA is 
easier if you're on Ubuntu, no question about that.  But that doesn't 
mean you will get Debian administrators to deal with them.

-You can build a repo installer package that simplifies some of the 
keyring and repo setup tasks.  For example, the Debian installer for 
Google Chrome has a postinst step that drops a file into 
/etc/apt/sources.list.d/google-chrome.list with the repo information and 
it pulls in the signing key.  *These are considered unwelcome things by 
some Debian users*!  Typical complaint: 
http://costela.net/2009/12/notes-on-the-google-chrome-debian-package/

There is some unresolvable distance between "the right way" of official 
Debian packages and "the easy way" of a PPA.  Everyone should recognize 
those are two slightly different markets, and you won't be able to 
satisfy both perfectly using one approach.  The yum repo eventually 
worked out how to provide a middle ground with an optional repo setup 
package.

The instructions at http://www.postgresql.org/download/linux/debian/ are 
a bit much right now, so some automation toward reducing them would be 
useful.  Just be aware that such automation will need to happen with a 
Debian packaging expert involved, or it's likely to cause as many 
problems as it tries to solve.  Some complexity is unavoidable if you 
want to also satisfy the needs of the serious Debian administrator well. 
  I think it's not terrible that the current documentation will *only* 
satisfy such admins right now, just given the demographics of who uses 
Debian.  It's not ideal from a long-term support perspective though.

-- 
Greg Smith   2ndQuadrant US    [email-masked]   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

---

From: Magnus Hagander <[email-masked]>
Date: Tue, 19 Feb 2013 16:22:36 +0100

On Tue, Feb 19, 2013 at 4:07 PM, Greg Smith <[email-masked]> wrote:
> I'm using to seeing the short option version of this as "lsb_release -cs"
> instead.  Being able to tell Debian from Ubuntu is one of the points of
> lsb_release.  Note that lsb_release works on RHEL/RPM systems, too, but good
> naming there doesn't go back as far.  RHEL6 is codename "Carbon",  but RHEL5
> was "Final".

Yeah, lsb_release is, as the name kind of indicates, a requirement for
a LSB system.

> The amount of hysterics relative to forward progress in this discussion has
> been a bit high.  A few observations:

+1.

FYI, though, there has been some productive discussion in the IRC
channel on the topic, and people are moving forward to improve this.

> published by postgresql.org would be useful as a replacement for

Are you (or anybody) aware of if there are any automated ways to
actually do that? Without moving the development to launchpad. There
is a *lot* of advantages to having a shared build environment for the
debian and ubuntu packages, all the way from source patch to
"apt-ready package". I really don't want to give that up. But if it
can easily be mirrored onto launchpad, I see no issue with that.

> hacks, and you will never get many skilled Debian administrators to use one
> for defensible reasons.  The apt repo vs. PPA flame war is large, political,
> and best avoided; it can't be resolved here.  Using a PPA is easier if
> you're on Ubuntu, no question about that.  But that doesn't mean you will
> get Debian administrators to deal with them.

Using PPA is easier on Ubuntu, and bad on debian unless we encourage
people to apply hacks to their systems. We should not encourage people
to apply hacks to their systems.

Using a generic APT repository works for both, with about an equal
amount of work. Debian people are likely to be more experienced in
doing it, so it carries a slight favor to the debian side.

But it really is a difference between "easier" and "impossible". We
can *not* go with just a PPA. If we want a PPA, we need to do both.

> -You can build a repo installer package that simplifies some of the keyring
> and repo setup tasks.  For example, the Debian installer for Google Chrome
> has a postinst step that drops a file into
> /etc/apt/sources.list.d/google-chrome.list with the repo information and it
> pulls in the signing key.  *These are considered unwelcome things by some
> Debian users*!  Typical complaint:

Yes, they do a number of things you're not "supposed to do" on debian.
Our packages are actually *very* well behaved on debian and ubuntu,
and that is a property we should work hard to keep. That doesn't mean
we can't improve the installation experience, of course.

> those are two slightly different markets, and you won't be able to satisfy
> both perfectly using one approach.  The yum repo eventually worked out how
> to provide a middle ground with an optional repo setup package.
>
> The instructions at http://www.postgresql.org/download/linux/debian/ are a
> bit much right now, so some automation toward reducing them would be useful.
> Just be aware that such automation will need to happen with a Debian
> packaging expert involved, or it's likely to cause as many problems as it
> tries to solve.  Some complexity is unavoidable if you want to also satisfy
> the needs of the serious Debian administrator well.  I think it's not
> terrible that the current documentation will *only* satisfy such admins
> right now, just given the demographics of who uses Debian.  It's not ideal
> from a long-term support perspective though.

Yes. This is why we have multiple debian packaging experts in the
project. And also people who know some things about debian packages
and some things about usual customers, to bridge the gap ;)

Just to keep people informed, the current plan which is the latest
conclusion in the IRC discussion amongst the packagers is:

* Change the package pinning to be less conservative, and more with
what most people want. That will remove one step from the installation
instructions. Obviously this needs some lead time, but shouldn't be
too much.

* Create an automated script that will set the repository up for
people. This can either be downloaded and run, or it can be downloaded
as a signed https download and piped directly to the shell for those
daring people who trust postgresql.org.

* This will *not* mean we remove the documentation - the complete
manual setup instructions will remain for expert users. But we'll push
an automated way above them.

---

From: Martin Pitt <[email-masked]>
Date: Tue, 19 Feb 2013 16:36:32 +0100

> and some things about usual customers, to bridge the gap ;)

I think I can claim to have a sufficient understanding of how Debian
and Ubuntu archives and packaging work to offer to write such a
script. :-)

> instructions. Obviously this needs some lead time, but shouldn't be

I'm very much in favor of this.

> daring people who trust postgresql.org.

My current idea is to ship both the GPG key and the script in the
Debian/Ubuntu postgresql-common package. This closes the
authentication loophole in the sense that you can trust to get the
real postgresql archive if you trust that you have the real Debian
archive, and it doesn't need scary "wget | sudo bash" hacks.

So in theory this script could also set up the apt pinning, but I'd
rather not, because (1) doing that automatically would be besides the
point of having the pinning requirement in the first place, and (2)
automatically doing this can potentially break an already existing
(unrelated) apt pin configuration in "interesting" ways.

> an automated way above them.

Yes, of course.

Thank you!

Martin

---

From: Devrim GÜNDÜZ <[email-masked]>
Date: Tue, 19 Feb 2013 17:37:36 +0200

Hi,

> necessary as well on redhat if you want to override the distribution

So, website needs an update. As of 9.0, this is no longer required. I
did some magic in the RPMs that would probably don't need this. Just
removed this text.

Regards,

---

From: Martin Pitt <[email-masked]>
Date: Tue, 19 Feb 2013 16:39:20 +0100

> are different from the Debian code names, even though Ubuntu is based on

That's necessary because the two have wildly differing release cycles.

> Do we actually create different packages for Debian and Ubuntu?

They share the same source packages; I keep a single source package
that works on all currently supported Debian and Ubuntu versions; but
the binary packages differ depending on where you build them, in
particular library dependencies, supported Python versions, and the
like.

Thanks,

Martin

---

From: Magnus Hagander <[email-masked]>
Date: Tue, 19 Feb 2013 16:40:40 +0100

> and Ubuntu archives and packaging work to offer to write such a

Most definitely.

(BTW, this proves which debian packager wasn' tin the IRC channel at
the time :P)

> archive, and it doesn't need scary "wget | sudo bash" hacks.

Unfortunately, it will take quite a while to propagate, no?

What we were considering was using a curl | sudo bash basically. It
will then be signed by our main SSL certificate, so that should be
almost as trustworthy as a package signature (ours would be
exploitable by somebody tricking a public CA into giving them a cert
for www.postgresql.org)

> (unrelated) apt pin configuration in "interesting" ways.

Yeah, +1.

---

From: Martin Pitt <[email-masked]>
Date: Tue, 19 Feb 2013 16:41:18 +0100

Bruce Momjian [2013-02-19  8:44 -0500]:
> my release until I had to track a bug report a few months ago.

Believe it or not, that's actually great to hear :) The code names are
mostly some fun thing for developers to avoid breaking our tongues too
much when we talk about it. But they have never been meant to be
exposed in stable releases. All announcements, web sites, etc. always
say "Ubuntu 12.04", not "Precise Pangolin".

(I guess that also has something to do with seriousness and marketing,
etc. :-)

Martin

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 19 Feb 2013 10:47:01 -0500

> (I guess that also has something to do with seriousness and marketing,

Specificially, the patch I needed was ported to quetzal, and I had to
wait for it to be ported to precise.  I saw the names on the "Pending
Ubuntu stable release updates" page:

	http://people.canonical.com/~ubuntu-archive/pending-sru.html

and in discussions about the patch.

---

From: Martin Pitt <[email-masked]>
Date: Tue, 19 Feb 2013 16:50:44 +0100

---

From: Martin Pitt <[email-masked]>
Date: Tue, 19 Feb 2013 16:53:30 +0100

> - only supported a few versions of pg, not all supported ones

Right, only those which were supported in any Ubuntu release. E. g.
9.0 has never been in any Ubuntu release, thus there's nothing to
backport them from.

> - regularly dropped releases while they were still supported by PGDG

To be fair, I only drop packages for obsolete Ubuntu releases. And
after people have yelled loud enough, I even put them back.

> for the version youre using.

If you run a production server on an EOLed Ubuntu release, you
shouldn't complain. You are not going to get any security update any
more, so staying at a slightly outdated PostgreSQL version is really
not making much of a difference.

Thanks,

Martin

---

From: Andres Freund <[email-masked]>
Date: Tue, 19 Feb 2013 17:01:41 +0100

> not making much of a difference.

I am pretty sure you had some versions (e.g. 9.0) in your ppa for some
time, and dropped them afterwards, probably for the above reason that it
was never in a stable release.

Just to make that very, very clear: I am not blaming you for
anything. To the contrary. Your PPA is/was great, and the effort is
very, very much appreciated. Its just that apt.pg.o promises and
hopefully delivers more.

Greetings,

Andres Freund

---

From: Martin Pitt <[email-masked]>
Date: Tue, 19 Feb 2013 17:01:56 +0100

> Unfortunately, it will take quite a while to propagate, no?

Yes, but it took a long time to set up apt.p.o, and the PPA won't
disappear anytime soon anyway. This is also something which we can
backport to 12.04 LTS, and 10.04 LTS' lifetime isn't that long any
more anyway. For Debian, there's a good chance we can get it into the
next release (wheezy); it's in deep freeze, but that's a low-risk
change.

> exploitable by somebody tricking a public CA into giving them a cert

That seems fine indeed. There's nothing wrong with having more than
one way -- if you have the local script, use that, otherwise use above
approach?

Thanks,

Martin

---

From: Greg Smith <[email-masked]>
Date: Tue, 19 Feb 2013 13:52:09 -0500

On 2/19/13 10:22 AM, Magnus Hagander wrote:
>> Typical complaint:

That was the main thing I thought was being talked past.  Some people 
look at the ease of use of a PPA or the Debian Chrome installer and 
think "why isn't PostgreSQL this easy?"  It could be, and if Martin is 
willing to pull some more infrastructure into postgresql-common that 
would make things a lot smoother.

The reasons why a really simple UI wasn't the first target for something 
worth shipping are hard to understand.  You need to have spent a good 
bit of time packaging for Debian to appreciate why the Chrome install 
smells funny to some.  I just barely get it myself.  You can't really 
nail a PPA style release and something that makes all the Debian admins 
happy at the same time.  There's a deep and not obvious disconnect 
between the goals of each type of packaging.  I read "We should not 
transition to apt.postgresql.org until we have a PPA" as being like "we 
shouldn't release the apple juice until we have the perfect oranges". 
All important things, but they're not the same target.

---

From: Josh Berkus <[email-masked]>
Date: Tue, 19 Feb 2013 11:26:19 -0800

Greg, all,

> There's a deep and not obvious disconnect

So that seems like we should have, and continue to have to the limit of
our resources, both kinds of packaging.  Something simplified for the
most common case (current postgres/current OS release) and something
complete for the professional sysadmins.

The reason I started this thread in the first place was that I added the
PPA to a server and got a message, on the server, that the PPA was being
deprecated *very soon* in favor of apt.postgresql.org.  I'd have nothing
to complain about apt.postgresql.org if you weren't taking my PPA away.

So possibly the "fix" for this is just to stop the deprecation message
in the PPA until more of the development path (including some automation
scripts) of apt.postgresql.org is complete.  Depending on Martin's time
availability, of course.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

---

From: Josh Berkus <[email-masked]>
Date: Tue, 19 Feb 2013 11:42:09 -0800

> say "Ubuntu 12.04", not "Precise Pangolin".

Except that apt.postgresql.org says "Precise Pangolin" and DOESN'T say
Ubuntu 12.04.

Warning: Tangent follows.

Bringing it up only because two people asked "what's the big deal with
code names?"  Most people should probably ignore this.

The reason why people who are not full-time Ubuntu or Debian admins hate
the code names is that they are used inconsistently by the projects, and
you are expected to "just know" what they mean.  Ubuntu is especially
bad about this, using the release date numbering in all its official
correspondence (e.g. Ubuntu 12.04) but then using the code names
exclusively in the software repositories, and sometimes even the
*abbreviated* versions of the code names only, without supplying an
easy-to-find mapping anywhere.  Generally if I want to find out the code
name for 11.10, for example, I have to go onto #ubuntu and ask.  And
don't get me started on "Must be using Pangolin or later".

For someone who admins many servers running many different OSes, this is
a constant PITA, and forces me to take more time figuring out how to
upgrade software on Ubuntu than it takes me with other OSes, even
Windows, whose version names are highly arbitrary, but at least are
consistent and few in number.  Although lately Apple is even worse,
using code names inconsistenly which aren't even alphabetical, and using
code names which are remarkably similar ("Lion" vs. "Snow Lion"?  Really?).

Debian and Ubuntu community members do not see this as a problem because
they assume you are immersed in their world and thus carry around a
Debian and/or Ubuntu release history in your head.  But most people don't.

I'm sure that Postgres has it's only parallels to this kind of problem
(not the least of which is the project name), but I don't know that
anyone regards those warts as *features*.

End tangent.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

---

From: Martin Pitt <[email-masked]>
Date: Wed, 20 Feb 2013 07:36:53 +0100

Hey Josh,

> scripts) of apt.postgresql.org is complete.  Depending on Martin's time

Fair enough. I changed it like this now:

  https://launchpad.net/~pitti/+archive/postgresql

Does that sound like a reasonable compromise?

Thanks,

Martin

---

From: Magnus Hagander <[email-masked]>
Date: Wed, 20 Feb 2013 17:05:44 +0100

> next release (wheezy); it's in deep freeze, but that's a low-risk

Yeah. It would be very nice to get it in there for future work, but we
definitely need to put something else in place before then. But let's
do both :)

> one way -- if you have the local script, use that, otherwise use above

Yeah, that's what I'd suggest.

---

From: Josh Berkus <[email-masked]>
Date: Wed, 20 Feb 2013 09:48:18 -0800

> Does that sound like a reasonable compromise?

WFM.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

---

From: Josh Berkus <[email-masked]>
Date: Tue, 26 Feb 2013 13:12:42 -0800

Apt folks,

What's the reason that .10 versions of Ubuntu aren't supported?  Is
there a plan to support them in the future?  Is it a resource issue?

Again, this is a regression from the PPA.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

---

From: Martin Pitt <[email-masked]>
Date: Wed, 27 Feb 2013 06:47:33 +0100

Hello Josh,

Josh Berkus [2013-02-26 13:12 -0800]:
> What's the reason that .10 versions of Ubuntu aren't supported?

Combinatorial explosion I would think, so space and build time issues.
Also, it's really not that important; a package built for 12.04 LTS
will run just fine on 12.10. The only thing which breaks running
binaries for older distro releases is a newer Perl version, but that
hasn't happened after a while. If/when it happens again, we will need
a build for that newer release indeed, but Christoph said that we can
do that.

Martin

---

From: Josh Berkus <[email-masked]>
Date: Wed, 27 Feb 2013 11:05:45 -0800

> a build for that newer release indeed, but Christoph said that we can

Ah, ok.  We had trouble installing the 12.04 version on 12.10 when we
tested it, but I'll take that up on a different list.   Thanks.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

---

From: "Joshua D. Drake" <[email-masked]>
Date: Wed, 27 Feb 2013 11:18:36 -0800

> tested it, but I'll take that up on a different list.   Thanks.

Then shouldn't we just say that the 12.04 and 12.10 packages are identical?

JD

---

From: Josh Berkus <[email-masked]>
Date: Fri, 01 Mar 2013 10:38:43 -0800

Folks,

One of our staff, Jeff Frost, has written a script to make installation
of the new apt.postgresql.org repository easier.  Please evaluate
whether it makes sense to include it in the instructions:
 https://github.com/pgexperts/add-pgdg-apt-repo

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

---

From: Magnus Hagander <[email-masked]>
Date: Fri, 1 Mar 2013 19:43:39 +0100

>  https://github.com/pgexperts/add-pgdg-apt-repo

Is fairly close to the stuff we were discussing to do. For one, it should
use https and not http, but that requires server side changes so it makes
sense Jeff couldn't do that. The complete lack of error checking if
obviously not very good. But the basic principle is certainly right.

/Magnus

---

From: Christophe Pettus <[email-masked]>
Date: Fri, 1 Mar 2013 10:44:57 -0800

On Mar 1, 2013, at 10:43 AM, Magnus Hagander wrote:

> Is fairly close to the stuff we were discussing to do. For one, it should use https and not http, but that requires server side changes so it makes sense Jeff couldn't do that. The complete lack of error checking if obviously not very good. But the basic principle is certainly right.

Then it is worth Jeff continuing development of it?

--
-- Christophe Pettus
   [email-masked]

---

From: Magnus Hagander <[email-masked]>
Date: Mon, 4 Mar 2013 08:56:03 +0100

> Then it is worth Jeff continuing development of it?

As a matter of principle, I don't see why not - though I'm not sure
how much of this stuff Christoph has already done?

---

From: Christoph Berg <[email-masked]>
Date: Tue, 5 Mar 2013 10:23:56 +0100

Re: Magnus Hagander 2013-03-04 <CABUevEzBH4K=[email-masked]>
> how much of this stuff Christoph has already done?

If we are providing a shell script, it should contain the key.

The script we have in postgresql-common now is attached, if the bzr
frontend on bzr.debian.org were not dead at the moment, the URL would
be:

http://anonscm.debian.org/loggerhead/pkg-postgresql/postgresql-common/trunk/annotate/1296/pgdg/apt.postgresql.org.sh

Christoph

---

From: Christoph Berg <[email-masked]>
Date: Tue, 5 Mar 2013 10:56:21 +0100

Re: To Magnus Hagander 2013-03-05 <[email-masked]>
> frontend on bzr.debian.org were not dead at the moment, the URL would

They fixed it. Here's a link to the head revision:

http://anonscm.debian.org/loggerhead/pkg-postgresql/postgresql-common/trunk/annotate/head:/pgdg/apt.postgresql.org.sh

Christoph