On Nov 16, 2016 11:10, "Devrim Gündüz" <devrim@gunduz.org> wrote:
>
>
> Hi,
>
> On Wed, 2016-11-16 at 09:54 +0000, Dave Page wrote:
> > > Not at all knowing what Devrim was thinking, but perhaps you need something
> > > like what postgresql.org does for "difficult build dependencies". Which is
> > > build a snapshot tarfile that includes the *prebuilt* documentation, and
> > the
> > > same for releases of course. They don't go in git, but they go in the
> > > tarballs (we do that both for the docs and for things like the bison output
> > > in pg.org). And the tarballs contain nothing platform-specific (I assume),
> > > so they can be built on a platform that has easy access to those tools.
> >
> > Yeah, that could work. Though "difficult dependencies" is a stretch
> > here - it's really just that sphinx hasn't been updated in EPEL in
> > ages. It might be easiest to just get that RPM refreshed and be done
> > with it.
>
> I can do it in the community repo, but not sure if EPEL update will be accepted
> (I have the power to do so, but EPEL policy may be boring sometimes)
>
> I'll take a look. I already added 20+ more packages to community repo for
> pgadmin4. Adding another may not hurt, hopefully, at least for the build
> servers.
Uh, are you suggesting to put sphinx in the pgdg repo? If so, strong -1 from me for doing that. It seems like a horrible idea. It's a *build* dependency, not a runtime one.
20 runtime dependencies is already pretty bad. Isn't there a risk of a potential conflict if somebody has both say pgdg and epel enabled if they carry incompatible versions?
/Magnus