On Nov 16, 2016 11:10, "Devrim Gündüz" <dev...@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
