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

On Tue, Feb 19, 2013 at 4:07 PM, Greg Smith <greg(at)2ndquadrant(dot)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/