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