Re: Jonathan S. Katz 2019-02-27 <14f521d7-bfbc-7fb3-df26-3ccf9c1c79d5@postgresql.org>
> 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?
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.
> 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).
(See above)
> 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)
That's a leftover from when it was first written 5 years ago. Fixable.
> 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?
"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.
> 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.
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.
> 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']
Will fix.
> 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 :)
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
