Peter Eisentraut wrote:
>
> Karl DeBisschop writes:
>
> > PostgreSQL builds are great for the portability. The next logical step
> > might in fact be to extend some of that consistency to the package
> > creation arena.
>
> This would have been cool in 1996. We would have evolved a large number
> of different packages along with the build system. But it didn't happen
> this way and now most packages are sufficiently contorted in a number of
> ways because of vendor requirements, different ideas of how an operating
> system is supposed to work, self-inflicted incompatibilities, and a number
> of other reasons, including not least importantly the desire to have
> control over what ships in your system. All valid reasons, of course.
>
> If we can work at, and succeed at, resolving most of these oddities, then
> tracking packages in the source tree might prove worthwhile. But as long
> as we're still required to keep track what vendor has 'chkconfig' or what
> version of what distribution has broken CFLAGS, to list some trivial
> things, as long as the packages need to track anything but the development
> of PostgreSQL itself, this undertaking is going to become a problem.
>
> What would be worthwhile is setting up another cvs module so packages can
> be developed and released at their own pace.
I think on the biggest point we agree. Working with packagers and making
that job easier and more consistent is a good thing, (so long as it does
not interfere with development on postgresql itself, of course).
On the projects I am involved with, however, my experience of what work
has been contary to the tactics you suggest for reaching tha goal. I
found it easiest to develop in close concert with packagers, and in my
case that meant hosting the various packaging scripts within the source
tree. Of course that was for smaller projects with much less legacy than
postgresql, so maybe it doesn't apply here.
I still think it would be cool to download just the tarball from the
site and have a little 'mkpackage' script that I run on solaris to get
the cannonical solaris packages, on Red Hat to get the cannonical Red
Hat rpms, on FreeBSD to get the cannonical port, etc. Maybe a ways off,
but an appealing end goal to me.
It would be even better if by unifying support of the packaging process,
the differences between install would be limited to the requirements of
each OS, and not be dictated by the personal whims of the packager. I
know Lamar and Oliver keep in close contact so their packages don't get
too idiosyncratic. I'm advocating any process that helps extend that
spirit across the board.
--
Karl
