Thread: Re: [pgsql-www] We should not transition to apt.postgresql.org until we have a PPA

Re: Martin Pitt 2013-02-14 <20130214055510.GB3119@piware.de>
> Tom Lane [2013-02-13 18:34 -0500]:
> > 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.

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

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

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
--
cb@df7cb.de | http://www.df7cb.de/

Christoph Berg [2013-02-14 10:29 +0100]:
> 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.

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

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

Re: Martin Pitt 2013-02-14 <20130214094217.GH3042@piware.de>
> Christoph Berg [2013-02-14 10:35 +0100]:
> > 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.
>
> 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.

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 <20130214094416.GI3042@piware.de>
> Christoph Berg [2013-02-14 10:29 +0100]:
> > 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.
>
> 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.

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
--
cb@df7cb.de | http://www.df7cb.de/

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

On 02/14/2013 10:35 AM, Josh Berkus wrote:
>
> Folks,
>
> (1) Issue with instructions on Ubuntu 12.04
>
> 1. install the key using the wget command.

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

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

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



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

On 02/14/2013 07:35 PM, Josh Berkus wrote:
> Folks,
>
> (1) Issue with instructions on Ubuntu 12.04
>
> 1. install the key using the wget command.

and that is a problem?

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

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

>
> ===========
>
> (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.


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.

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

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

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

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.


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

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.


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

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

On Thu, Feb 14, 2013 at 09:51:45PM +0100, Stefan Kaltenbrunner wrote:
> > (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.
>
>
> 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.

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  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

Re: Bruce Momjian 2013-02-16 <20130216013854.GD12029@momjian.us>
> 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.

>     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

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.

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

"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.)

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

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

Christoph
--
cb@df7cb.de | http://www.df7cb.de/

On Sat, Feb 16, 2013 at 09:44:22AM +0100, Christoph Berg wrote:
> Re: Bruce Momjian 2013-02-16 <20130216013854.GD12029@momjian.us>
> > 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.

OK.  How do people find their codename?

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

Yes, that is much better.

> > as in:
> >
> >     sudo cat > /etc/apt/preferences.d/pgdg.pref <<END
> >     Package: *
> >     Pin: release o=apt.postgresql.org
> >     Pin-Priority: 500
> >     END
>
> "Write this to disk as root" is suprisingly hard in shell. Your
> 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"

>     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

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

> 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.)
>
> > Folks, we shouldn't be requiring decoder rings here to install Postgres
> > --- we have to do better.
>
> 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.

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

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

On Sat, Feb 16, 2013 at 10:33:09AM -0500, Bruce Momjian wrote:
> On Sat, Feb 16, 2013 at 09:44:22AM +0100, Christoph Berg wrote:
> > Re: Bruce Momjian 2013-02-16 <20130216013854.GD12029@momjian.us>
> > > 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.
>
> OK.  How do people find their codename?

OK, I found the answer:

    $ lsb_release --short --codename
    squeeze

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

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.

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

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

Bruce Momjian wrote:
> On Sat, Feb 16, 2013 at 10:33:09AM -0500, Bruce Momjian wrote:
> > On Sat, Feb 16, 2013 at 09:44:22AM +0100, Christoph Berg wrote:
> > > Re: Bruce Momjian 2013-02-16 <20130216013854.GD12029@momjian.us>
> > > > 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.
> >
> > OK.  How do people find their codename?
>
> OK, I found the answer:
>
>     $ lsb_release --short --codename
>     squeeze

Uhm.

$ lsb_release
No LSB modules are available.


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

On Sun, Feb 17, 2013 at 02:40:28AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Sat, Feb 16, 2013 at 10:33:09AM -0500, Bruce Momjian wrote:
> > > On Sat, Feb 16, 2013 at 09:44:22AM +0100, Christoph Berg wrote:
> > > > Re: Bruce Momjian 2013-02-16 <20130216013854.GD12029@momjian.us>
> > > > > 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.
> > >
> > > OK.  How do people find their codename?
> >
> > OK, I found the answer:
> >
> >     $ lsb_release --short --codename
> >     squeeze
>
> Uhm.
>
> $ lsb_release
> No LSB modules are available.

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

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

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

Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Bruce Momjian wrote:

>> OK, I found the answer:
>>
>>     $ lsb_release --short --codename
>>     squeeze
>
> Uhm.
>
> $ lsb_release
> No LSB modules are available.

$ lsb_release
No LSB modules are available.
$ lsb_release --short --codename
quantal

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

Bruce Momjian wrote:
> On Sun, Feb 17, 2013 at 02:40:28AM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > On Sat, Feb 16, 2013 at 10:33:09AM -0500, Bruce Momjian wrote:
> > > > On Sat, Feb 16, 2013 at 09:44:22AM +0100, Christoph Berg wrote:
> > > > > Re: Bruce Momjian 2013-02-16 <20130216013854.GD12029@momjian.us>
> > > > > > 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.
> > > >
> > > > OK.  How do people find their codename?
> > >
> > > OK, I found the answer:
> > >
> > >     $ lsb_release --short --codename
> > >     squeeze
> >
> > Uhm.
> >
> > $ lsb_release
> > No LSB modules are available.
>
> Uh, that's what I get too.  Try it with the arguments I suggested,
> please.

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

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

Re: Bruce Momjian 2013-02-17 <20130216234034.GG12029@momjian.us>
> 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.

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
--
cb@df7cb.de | http://www.df7cb.de/

On Sat, Feb 16, 2013 at 1:38 AM, Bruce Momjian <bruce@momjian.us> wrote:
>
> Folks, we shouldn't be requiring decoder rings here to install Postgres
> --- 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

On Mon, Feb 18, 2013 at 09:25:15AM +0100, Christoph Berg wrote:
> Re: Bruce Momjian 2013-02-17 <20130216234034.GG12029@momjian.us>
> > 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.
>
> Well the original version had the advantage that it was
> 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?

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

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

On Mon, Feb 18, 2013 at 09:29:19AM -0500, Bruce Momjian wrote:
> On Mon, Feb 18, 2013 at 09:25:15AM +0100, Christoph Berg wrote:
> > Re: Bruce Momjian 2013-02-17 <20130216234034.GG12029@momjian.us>
> > > 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.
> >
> > Well the original version had the advantage that it was
> > 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?

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.

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

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

On 02/18/2013 10:15 AM, Dave Page wrote:
> On Sat, Feb 16, 2013 at 1:38 AM, Bruce Momjian <bruce@momjian.us> wrote:
>>
>> Folks, we shouldn't be requiring decoder rings here to install Postgres
>> --- 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.

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

On Mon, Feb 18, 2013 at 6:23 PM, Stefan Kaltenbrunner
<stefan@kaltenbrunner.cc> wrote:
> On 02/18/2013 10:15 AM, Dave Page wrote:
>> On Sat, Feb 16, 2013 at 1:38 AM, Bruce Momjian <bruce@momjian.us> wrote:
>>>
>>> Folks, we shouldn't be requiring decoder rings here to install Postgres
>>> --- 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.
>
> 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.

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.

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

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

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

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

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

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!

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

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

On Mon, Feb 18, 2013 at 7:40 PM, Dave Page <dpage@pgadmin.org> wrote:
> On Mon, Feb 18, 2013 at 6:23 PM, Stefan Kaltenbrunner
> <stefan@kaltenbrunner.cc> wrote:
>> On 02/18/2013 10:15 AM, Dave Page wrote:
>>> On Sat, Feb 16, 2013 at 1:38 AM, Bruce Momjian <bruce@momjian.us> wrote:
>>>>
>>>> Folks, we shouldn't be requiring decoder rings here to install Postgres
>>>> --- 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.
>>
>> 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.
>
> 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.

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.


>> 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).
>
> 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/

On Thu, Feb 14, 2013 at 10:44 AM, Martin Pitt <mpitt@debian.org> wrote:
> Christoph Berg [2013-02-14 10:29 +0100]:
>> 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.
>
> 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.

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

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

On 2013-02-18 09:15:59 +0000, Dave Page wrote:
> On Sat, Feb 16, 2013 at 1:38 AM, Bruce Momjian <bruce@momjian.us> wrote:
> >
> > Folks, we shouldn't be requiring decoder rings here to install Postgres
> > --- 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.

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

On Mon, Feb 18, 2013 at 6:47 PM, Magnus Hagander <magnus@hagander.net> wrote:
>>> 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.
>>
>> 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.
>
> 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.

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.

> I haven't seen a single email expressing that problem since we put the
> 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.

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

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

On Mon, Feb 18, 2013 at 4:12 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-02-18 09:15:59 +0000, Dave Page wrote:
>> On Sat, Feb 16, 2013 at 1:38 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> >
>> > Folks, we shouldn't be requiring decoder rings here to install Postgres
>> > --- 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.
>
> 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.

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.

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

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.

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

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

On 02/18/2013 07:40 PM, Dave Page wrote:
> On Mon, Feb 18, 2013 at 6:23 PM, Stefan Kaltenbrunner
> <stefan@kaltenbrunner.cc> wrote:
>> On 02/18/2013 10:15 AM, Dave Page wrote:
>>> On Sat, Feb 16, 2013 at 1:38 AM, Bruce Momjian <bruce@momjian.us> wrote:
>>>>
>>>> Folks, we shouldn't be requiring decoder rings here to install Postgres
>>>> --- 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.
>>
>> 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.
>
> 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.
>
>> 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).
>
> 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

well so far so good - BUT...


>
>
> 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
>
> deb http://apt.postgresql.org/pub/repos/apt/ squeeze-pgdg main
>
> 3) Configure apt's package pinning to prefer the PGDG packages over
> the standard ones in /etc/apt/preferences.d/pgdg.pref
>
> Package: *
> Pin: release o=apt.postgresql.org
> Pin-Priority: 500

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

Stefan,

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

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.

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

You clearly haven't tried to follow both procedures from scratch, let
alone tried to teach them to anyone else.

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.

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.

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.

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

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

On 02/18/2013 09:07 PM, Josh Berkus wrote:
> Stefan,
>
>> 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.
>
> 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.
>
>> 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).
>
> 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

On 2013-02-19 07:14:25 +1100, Brendan Jurd wrote:
> 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?

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

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

On 02/18/2013 09:14 PM, Brendan Jurd wrote:
> 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?

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.

> If it's important to have apt.postgresql.org for other reasons, then
> 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

On Mon, Feb 18, 2013 at 6:40 PM, Dave Page <dpage@pgadmin.org> wrote:
> 3) Configure apt's package pinning to prefer the PGDG packages over
> the standard ones in /etc/apt/preferences.d/pgdg.pref
>
> Package: *
> Pin: release o=apt.postgresql.org
> Pin-Priority: 500

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

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

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

On Mon, Feb 18, 2013 at 11:58 PM, Josh Berkus <josh@agliodbs.com> wrote:
> 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

Hi,

Dave Page <dpage@pgadmin.org> writes:
> 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.

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

Magnus Hagander <magnus@hagander.net> writes:
>> 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.
>
> +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.

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

Brendan Jurd <direvus@gmail.com> writes:
> 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?

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,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

On Mon, Feb 18, 2013 at 7:12 PM, Stefan Kaltenbrunner
<stefan@kaltenbrunner.cc> wrote:
>
> 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...

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

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

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

On Tue, Feb 19, 2013 at 12:22 AM, Greg Stark <stark@mit.edu> wrote:
> On Mon, Feb 18, 2013 at 11:58 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> 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.

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

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

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.

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

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

On Tue, Feb 19, 2013 at 9:26 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Hi,
>
> Dave Page <dpage@pgadmin.org> writes:
>> 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.
>
> 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.

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.

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

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

Dave Page <dpage@pgadmin.org> writes:
> 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.

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,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

On Sun, Feb 17, 2013 at 11:08:25PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Sun, Feb 17, 2013 at 02:40:28AM -0300, Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > > > On Sat, Feb 16, 2013 at 10:33:09AM -0500, Bruce Momjian wrote:
> > > > > On Sat, Feb 16, 2013 at 09:44:22AM +0100, Christoph Berg wrote:
> > > > > > Re: Bruce Momjian 2013-02-16 <20130216013854.GD12029@momjian.us>
> > > > > > > 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.
> > > > >
> > > > > OK.  How do people find their codename?
> > > >
> > > > OK, I found the answer:
> > > >
> > > >     $ lsb_release --short --codename
> > > >     squeeze
> > >
> > > Uhm.
> > >
> > > $ lsb_release
> > > No LSB modules are available.
> >
> > Uh, that's what I get too.  Try it with the arguments I suggested,
> > please.
>
> Oh, what a weird program.  Yes, I get "wheezy" with your suggested
> options.

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?

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

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

On Tue, Feb 19, 2013 at 1:03 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Sun, Feb 17, 2013 at 11:08:25PM -0300, Alvaro Herrera wrote:
>> Bruce Momjian wrote:
>> > On Sun, Feb 17, 2013 at 02:40:28AM -0300, Alvaro Herrera wrote:
>> > > Bruce Momjian wrote:
>> > > > On Sat, Feb 16, 2013 at 10:33:09AM -0500, Bruce Momjian wrote:
>> > > > > On Sat, Feb 16, 2013 at 09:44:22AM +0100, Christoph Berg wrote:
>> > > > > > Re: Bruce Momjian 2013-02-16 <20130216013854.GD12029@momjian.us>
>> > > > > > > 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.
>> > > > >
>> > > > > OK.  How do people find their codename?
>> > > >
>> > > > OK, I found the answer:
>> > > >
>> > > >         $ lsb_release --short --codename
>> > > >         squeeze
>> > >
>> > > Uhm.
>> > >
>> > > $ lsb_release
>> > > No LSB modules are available.
>> >
>> > Uh, that's what I get too.  Try it with the arguments I suggested,
>> > please.
>>
>> Oh, what a weird program.  Yes, I get "wheezy" with your suggested
>> options.
>
> 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?

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


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

On 02/19/2013 01:03 PM, Bruce Momjian wrote:
> 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.

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*

On Tue, Feb 19, 2013 at 02:10:58PM +0100, Markus Wanner wrote:
> On 02/19/2013 01:03 PM, Bruce Momjian wrote:
> > 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.
>
> 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

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.

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

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

On 02/19/2013 02:20 PM, Bruce Momjian wrote:
> 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.

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

On Tue, Feb 19, 2013 at 02:30:17PM +0100, Markus Wanner wrote:
> On 02/19/2013 02:20 PM, Bruce Momjian wrote:
> > 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.
>
> 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.  :-)

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.

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

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

On 02/19/2013 02:44 PM, Bruce Momjian wrote:
> 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.

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

On 2/19/13 7:03 AM, Bruce Momjian wrote:

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

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    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

On Tue, Feb 19, 2013 at 4:07 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> On 2/19/13 7:03 AM, Bruce Momjian wrote:
>
>> 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.
>
>
> 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.


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

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.


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

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:
> http://costela.net/2009/12/notes-on-the-google-chrome-debian-package/

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.


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

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.


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

Magnus Hagander [2013-02-19 16:22 +0100]:
> > 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.

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

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. :-)

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

I'm very much in favor of this.

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

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.

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

Yes, of course.

Thank you!

Martin

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

Hi,

On Mon, 2013-02-18 at 20:12 +0100, Stefan Kaltenbrunner wrote:

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

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,

Bruce Momjian [2013-02-19  7:03 -0500]:
> 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.

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
--
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

On Tue, Feb 19, 2013 at 4:36 PM, Martin Pitt <mpitt@debian.org> wrote:
> Magnus Hagander [2013-02-19 16:22 +0100]:
>> > 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.
>
>> 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 ;)
>
> 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. :-)

Most definitely.

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


>> 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.
>
> I'm very much in favor of this.
>
>> * 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.
>
> 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.

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)


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

Yeah, +1.


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

Bruce Momjian [2013-02-19  8:44 -0500]:
> 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.

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
--
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

On Tue, Feb 19, 2013 at 04:41:18PM +0100, Martin Pitt wrote:
> Bruce Momjian [2013-02-19  8:44 -0500]:
> > 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.
>
> 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. :-)

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.

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

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

Brendan Jurd [2013-02-19  7:14 +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?

From my POV it's really not about the technical implementation of the
archive (PPA or otherwise). It's because apt.p.o has a lot more
packages, in particular extensions or pgadmin, and also because it's
got a really nice automatic Jenkins deployment and testing system
which ensures that all integration regression tests succeed before a
package hits the world.

I. e. it centralizes all the efforts of backporting postgresql stuff.
In principle you can do the very same with a PPA as well, but at the
end of the day users shouldn't really care what we call "that thing
over there that gives me packages" like, as long as there's a simple
way to get it?

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

Making it smell "official" is certainly an aspect. But OTOH I'm quite
surprised how many people use my PPA, so it doesn't seem to be much of
a concern :-)

> I guess I just don't understand why in Zeus' beard we would move away
> from the PPA arrangement.

I'm not pushing to move away from a PPA, but away from having to do
duplicate work, and wanting to close my rather small PPA for the
comparatively rich set of packages that apt.p.o offers.

Thanks,

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

Andres Freund [2013-02-18 21:52 +0100]:
> The PPA:
> - 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.

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

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

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

Magnus Hagander [2013-02-19 16:40 +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.

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

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
--
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

On 2013-02-19 16:53:30 +0100, Martin Pitt wrote:
> Andres Freund [2013-02-18 21:52 +0100]:
> > The PPA:
> > - 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.

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

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

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

On 2/19/13 10:22 AM, Magnus Hagander wrote:
>> Typical complaint:
>> http://costela.net/2009/12/notes-on-the-google-chrome-debian-package/
>
> 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.

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.

--
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

Greg, all,


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

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

On 02/19/2013 07:41 AM, Martin Pitt wrote:
> Bruce Momjian [2013-02-19  8:44 -0500]:
>> 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.
>
> 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".

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

Hey Josh,

Josh Berkus [2013-02-19 11:26 -0800]:
> 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.

Fair enough. I changed it like this now:

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

Does that sound like a reasonable compromise?

Thanks,

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

On Tue, Feb 19, 2013 at 5:01 PM, Martin Pitt <mpitt@debian.org> wrote:
> Magnus Hagander [2013-02-19 16:40 +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.

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


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

Yeah, that's what I'd suggest.


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

> Fair enough. I changed it like this now:
>
>   https://launchpad.net/~pitti/+archive/postgresql
>
> Does that sound like a reasonable compromise?

WFM.


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

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

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
--
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

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

On 02/27/2013 11:05 AM, Josh Berkus wrote:
>
>
>> 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.
>
> 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.

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

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

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

On Mar 1, 2013 1:39 PM, "Josh Berkus" <josh@agliodbs.com> wrote:
>
> 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
>

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

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
serverside 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
   xof@thebuild.com

On Fri, Mar 1, 2013 at 7:44 PM, Christophe Pettus <xof@thebuild.com> wrote:
>
> 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
serverside 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?

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?

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

Re: Magnus Hagander 2013-03-04 <CABUevEzBH4K=zPAXWFTuFaYpOKP_h2_5XHgivWzbi6_LYEAdwg@mail.gmail.com>
> On Fri, Mar 1, 2013 at 7:44 PM, Christophe Pettus <xof@thebuild.com> wrote:
> >
> > 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
requiresserver side changes so it makes sense Jeff couldn't do that. The complete lack of error checking if obviously
notvery good. But the basic principle is certainly right. 
> >
> > 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?

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
--
cb@df7cb.de | http://www.df7cb.de/

Re: To Magnus Hagander 2013-03-05 <20130305092356.GA11586@msgid.df7cb.de>
> 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:

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
--
cb@df7cb.de | http://www.df7cb.de/