Re: Packaging 7.1.1
От | Karl DeBisschop |
---|---|
Тема | Re: Packaging 7.1.1 |
Дата | |
Msg-id | 3AF2CA89.4F246DEF@alert.infoplease.com обсуждение исходный текст |
Ответ на | RE: Packaging 7.1.1 (Rachit Siamwalla <rachit@ensim.com>) |
Ответы |
Re: Packaging 7.1.1
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: