Lamar Owen wrote:
>
> Tom Lane wrote:
> > Seems like that stuff should be in CVS somewhere ... if only so someone
> > else can pick up the ball if you get run over by a truck :-(.
>
> My wife appreciates the sentiment :-). As it stands now, better
> documentation distributed in the source RPM would help greatly.
> Everything necessary to do the build and maintain the package is in the
> source RPM as it stands now -- evidenced by the Linux distributors being
> able to take our source RPM, massage it to fit their particular system,
> and run with it. And I have a scad of history available in specfile
> form....
>
> > If it's just a small amount of code, I don't see what the harm would be
> > in including it in the regular distro, though we should talk about just
> > where it should go. If it's a large amount of code then perhaps a
> > separate CVS project would be better, so that people who have no use for
> > it don't end up pulling/downloading it.
>
> Not counting the JDBC jars, it's a hundred K or so uncompressed. The
> spec file is around 30k -- a small amount of code.
>
> contrib/rpm-dist?
Seems to work. But I would prefer to look at how ither packaging schemes
work and come up with something that might be consistent and useful
across the board.
For starters, I'd make contrib/package/
Then make an rpm subdirectory. Also a pkg directory for system that use
pkgmk/pkginfo/pkgadd/pkgrm. If there's a way to may debain packages paly
the game, put them in as well. Then, if someaone is packages for a
variety of systems, there is alt least the possibility of some small
amount of consistency.
Extending things, you could have contrib/package/rpm/redhat for
redhat-specific stuff. contrib/package/rpm/mandrake for mandrafke stuff.
You get the idea.
At that point, I could even imagine contrib/mkpackage script that di som
OS detection, and built wahtever you wanted. That may be a little far
off, but I think there is an important nuggent in here. Tarballs are
great for developers, but they are not that great for system
administrators with large installed bases. 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.
--
Karl