Subject: apt.postgresql.org django app for www.postgresql.org

From: Christoph Berg <[email-masked]>
Date: Tue, 22 Jan 2019 15:00:25 +0100

Hi,

We have implemented a repository browser for apt.postgresql.org to be
run on www.postgresql.org/repos/apt/. This has been in the works for
years, but has somehow never reached this list.

It is mostly feature-complete, i.e. browsing the list of supported
distributions, source and binary packages works. It supports searching
for packages and filenames in packages.

Dependencies:
python-apt, postgresql-*-debversion, pg_trgm (from postgresql-*-contrib)

To test, create a mirror of a (subset of) apt.postgresql.org:
* debmirror -v -h apt.postgresql.org -r pub/repos/apt --method=http -d sid-pgdg --omit-suite-symlinks -s main,12 -a source,amd64 --exclude='\.deb$' --getcontents --no-check-gpg /srv/repo
* set APT_DIR to that directory in settings_local.py
* run import-packagelists.py

TODO:
* The contained homepage at /repos/apt/ is an outdated mockup, the
  list of supported dists should be rendered from the database
* There are no links to /repos/apt/ from anywhere else in the pg.o
  page yet
* import-packagelists.py uses django to open the PG connection, but
  this should be rewritten to use plain psycopg2.
* The idea is that import-packagelists.py writes directly to the
  database, so appropriate GRANTs are needed to allow writing to the
  apt_* tables only
* The "qa" part contains queries that have not yet been ported from an
  older datamodel yet and is hence disabled
* There is no documentation yet

Still, it already works nicely if you point the browser directly at
/repos/apt, so please review :)

Christoph

---

From: Ray O'Donnell <[email-masked]>
Date: Tue, 22 Jan 2019 14:14:17 +0000

> years, but has somehow never reached this list.

[snip]

> /repos/apt, so please review :)

Maybe I was too quick off the mark, but I'm getting a 404 at the above URL.

Ray.

-- 
Raymond O'Donnell // Galway // Ireland
[email-masked]

---

From: Christoph Berg <[email-masked]>
Date: Tue, 22 Jan 2019 15:16:01 +0100

Re: Ray O'Donnell 2019-01-22 <[email-masked]>
> Maybe I was too quick off the mark, but I'm getting a 404 at the above URL.

That's why there's a patch attached :)

Christoph

---

From: Ray O'Donnell <[email-masked]>
Date: Tue, 22 Jan 2019 14:17:44 +0000

> That's why there's a patch attached :)

Ah, OK, I misunderstood - I thought it was up and running. :-)

Ray.

---

From: Christoph Berg <[email-masked]>
Date: Wed, 30 Jan 2019 16:48:03 +0100

Updated for python3. I had to fix several places where {{package}} was
rendered as "Package Object". The new syntax is {{package.package}}.

Christoph

---

From: Christoph Berg <[email-masked]>
Date: Wed, 27 Feb 2019 16:09:32 +0100

Re: To PostgreSQL WWW 2019-01-30 <[email-masked]>
> rendered as "Package Object". The new syntax is {{package.package}}.

Ping?

Christoph

---

From: "Jonathan S. Katz" <[email-masked]>
Date: Wed, 27 Feb 2019 10:29:25 -0500

>> rendered as "Package Object". The new syntax is {{package.package}}.

tl;dr I do think having a repo browser on pgweb would be nice, but we
need to solve a few fundamental questions first:

1. Will we make the same thing available for the yums?
2. What will be the manual overhead on the pgweb, pginfra, + release team?

And the rest of it:

This will take some involved review. I made a quick pass, and saw a few
things.

First, an off-list comment that Magnus had raised (amongst a few
others): is this be set up to handle RPM/YUM, and if not, what will it
take to get it there? (Will somewhat answer this below).

There are a few things that are immediate nonstarters for me:

1. There is a bunch of DDL hanging out in SQL files that should be in
the Django migration file (and in fact, I don't see a migration file)

2. There appear to be some hardcoded things specific to deb/apt (e.g.
"all" => "amd64") which would not work if we wanted to extend this to
rpm/yum. The question becomes can we / do we want to build a
one-size-fits-all system?

Also:

1. This appears to introduce an extension from PGXN, "debversion" -- I
don't believe we've added any pgxn extensions directly into pgweb (I may
be wrong) but we would have to see what that means from an
administration standpoint.

2. There seem to be some easy improvements to make in some of the logic:

def search(request):
    if 'package' in request.GET and request.GET['package']:
        package = request.GET['package']

becomes:

def search(request):
    if request.GET.get('package'):
        package = request.GET['package']

3. For now, the "active" booleans scare me until I understand how much
of this is automated and how much of this is manual. Adding more manual
steps to each release terrifies me, mostly because we have more than our
fair share at the moment :)

Thanks,

Jonathan

---

From: Christoph Berg <[email-masked]>
Date: Wed, 27 Feb 2019 16:42:56 +0100

Re: Jonathan S. Katz 2019-02-27 <[email-masked]>
> 1. Will we make the same thing available for the yums?

I don't think it is fair to burden the extra work of supporting yum on
the initial implementation of this. I don't think it makes much sense
to extend the system to support both via the same because the package
structures are really different (both because of deb vs. rpm and the
actual packaging structure). Of course it makes sense to think about
if we could share some infrastructure with yum, but I don't think that
would fly.

> 2. What will be the manual overhead on the pgweb, pginfra, + release team?

Basically none. I'd handle all the necessary database updates from the
atalia.postgresql.org host by integrating it into the "add new
package" workflow.

> take to get it there? (Will somewhat answer this below).

(See above)

> the Django migration file (and in fact, I don't see a migration file)

That's a leftover from when it was first written 5 years ago. Fixable.

> one-size-fits-all system?

"all" is a special snowflake in the Debian architecture list. The
repository solves that by including "all" in each Packages files for
all architectures. If information about an Arch:all package is
requested, we need to pull it from any of the "real" architectures.

> administration standpoint.

It would allow proper comparison of Debian version numbers, but I
think we aren't really using this anywhere, so it could just be
removed.

>         package = request.GET['package']

Will fix.

> fair share at the moment :)

There are the markers for "is this Debian release still active". This
would be up to me to handle from the apt.pg.o side. (We can't really
automate this.)

Thanks,
Christoph

---

From: Dave Page <[email-masked]>
Date: Wed, 8 Jul 2020 14:08:34 +0100

Hi

> > rendered as "Package Object". The new syntax is {{package.package}}.

 I spent a bunch of time playing with this, as I intend to get repo
browsing for both Yum and Apt onto the website.

There was quite a bit of work to do to get it working with modern versions
of Django and Python 3. Once I got through enough of that to start looking
at the actual functionality what I found was *really* comprehensive.
Unfortunately I think there's actually far more there than we should put on
the main website.

- I think the QA section is clearly something that's aimed at you as
maintainers of the apt repos. This definitely doesn't belong on the main
website in my opinion.

- The madison interface is also interesting (academically), but I think is
of little use to the vast majority of our users; I'm not even sure that the
majority of Debian/Ubuntu users would know about rmadison.

- Similarly, I think the binary and source package pages are far more
comprehensive than most of our users need or would care about.

One of the biggest barriers of adoption to PostgreSQL is the perceived
complexity, including that of getting it up and running. That's why I'm
spending a lot of time at the moment trying to simplify and clarify the
download and installation processes. I think what we have in this patch
will simply be information overload for most of our users.

My suggestion is that we incorporate a relatively simple browser into the
main website, which allows users to easily browse the available packages
and see the details of them. I already have the repo scanning part of that
done for both apt and yum, generating JSON output in a way that can be
integrated with our download server sync process, which can load that into
the website database.

I would support a separate site (probably under apt.enterprisedb.com) that
supports the level of functionality you have in your patch; and I think
much, if not all of the code you currently have could be used for that.
This could of course be linked from the main website.

Thanks.

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

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

---

From: Dave Page <[email-masked]>
Date: Wed, 8 Jul 2020 14:20:48 +0100

On Wed, Jul 8, 2020 at 2:08 PM Dave Page <[email-masked]> wrote:

> I would support a separate site (probably under apt.enterprisedb.com)
> that supports the level of functionality you have in your patch; and I
> think much, if not all of the code you currently have could be used for
> that. This could of course be linked from the main website.
>

Obviously that should be apt.postgresql.org :-)

EDB: http://www.enterprisedb.com

---

From: Christoph Berg <[email-masked]>
Date: Thu, 9 Jul 2020 11:31:36 +0200

Re: Dave Page
> Unfortunately I think there's actually far more there than we should put on

Hi Dave,

thanks for picking this up.

It's well possible that I overshot the goal when I picked this up from
Adrian and put more and more info into it.

> maintainers of the apt repos. This definitely doesn't belong on the main

Yeah that could go.

> majority of Debian/Ubuntu users would know about rmadison.

I'm using that daily on the Debian archive, and it would help me a lot
if it were there. But we don't have to link it from every page, it's
just some API endpoint, we don't have to confuse users by linking to
it.

> will simply be information overload for most of our users.

Ack. We can probably merge the source and binary views into a single
(bigger) page with less clutter that users would reach by default. We
can still have the detailed pages linked from that for users that need
to know the details. I'm sure we can find a way to do that that
doesn't spoil the complexity reduction idea.

> and see the details of them.

That'd be about what I said above, I think.

> I already have the repo scanning part of that

Is that online somewhere?

> This could of course be linked from the main website.

Maintaining two sets of interfaces is probably too much. I think we
can get the "main" one to work, we just need to remove lots of
clutter.

> Obviously that should be apt.postgresql.org :-)

That got me for a second. ;)

Christoph

---

From: Dave Page <[email-masked]>
Date: Fri, 10 Jul 2020 13:50:08 +0100

> Adrian and put more and more info into it.

:-)

> doesn't spoil the complexity reduction idea.

Yeah. As a side note, the other thing I'm trying to do is be fairly
consistent design-wise between apt, yum and zypp.

> Is that online somewhere?

No, but I've attached the WIP scripts. Comments welcome. Note that I've
studiously avoided using any modules or external utilities that are only
available on Debian/Ubuntu. Sample output for Apt looks like:

[
  {
    "Architecture": "arm64",
    "Build": "3.pgdg+1",
    "Description": "debug symbols for pg-rage-terminator-9.6",
    "Distribution": "sid",
    "Filename":
"pool/main/p/pg-rage-terminator/pg-rage-terminator-9.6-dbgsym_0.1.7-3.pgdg+1_arm64.deb",
    "Licence": "",
    "Maintainer": "Adrian Vondendriesch <[email-masked]>",
    "Package": "pg-rage-terminator-9.6-dbgsym",
    "Repo": "sid-pgdg-testing",
    "Version": "0.1.7"
  },
  {
    "Architecture": "arm64",
    "Build": "1.pgdg+1",
    "Description": "PostgreSQL management tool - GUI application\npgAdmin
is an open source administration and management tool for the\nPostgreSQL
database. It includes a graphical administration interface, an SQL\nquery
tool, a procedural code debugger and much more. The tool is designed
to\nanswer the needs of developers, DBAs and system administrators
alike.\n\nThis package installs the GUI application.",
    "Distribution": "sid",
    "Filename": "pool/main/p/pgadmin4/pgadmin4_4.21-1.pgdg+1_arm64.deb",
    "Licence": "",
    "Maintainer": "Debian PostgreSQL Maintainers <
[email-masked]>",
    "Package": "pgadmin4",
    "Repo": "sid-pgdg-testing",
    "Url": "https://www.pgadmin.org/",
    "Version": "4.21"
  }
]

And for Yum:

[
  {
    "Architecture": "ppc64le",
    "Build": "9.rhel7",
    "Description": "pgAgent is a job scheduler for PostgreSQL which may be
managed\nusing pgAdmin.",
    "Distribution": "rhel-7",
    "Filename":
"9.5/redhat/rhel-7-ppc64le/pgagent_95-3.4.0-9.rhel7.ppc64le.rpm",
    "Licence": "PostgreSQL",
    "Maintainer": "",
    "Package": "pgagent_95",
    "Repo": "9.5",
    "Url": "http://www.pgadmin.org/",
    "Version": "3.4.0"
  },
  {
    "Architecture": "ppc64le",
    "Build": "1.f25",
    "Description": "The PostgreSQL Audit extension (pgaudit) provides
detailed session\nand/or object audit logging via the standard PostgreSQL
logging\nfacility.\n\nThe goal of the PostgreSQL Audit extension (pgaudit)
is to provide\nPostgreSQL users with capability to produce audit logs often
required to\ncomply with government, financial, or ISO
certifications.\n\nAn audit is an official inspection of an individual's or
organization's\naccounts, typically by an independent body. The information
gathered by\nthe PostgreSQL Audit extension (pgaudit) is properly called an
audit\ntrail or audit log. The term audit log is used in this
documentation.",
    "Distribution": "rhel-7",
    "Filename":
"9.5/redhat/rhel-7-ppc64le/pgaudit10_95-1.0.5-1.f25.ppc64le.rpm",
    "Licence": "BSD",
    "Maintainer": "",
    "Package": "pgaudit10_95",
    "Repo": "9.5",
    "Url": "https://www.pgaudit.org",
    "Version": "1.0.5"
  }
]

> that

I have a suspicion that what I think would be appropriate for most of our
users wouldn't be enough for you. Definitely open to discussion though!

> That got me for a second. ;)

Yeah, muscle memory :-p