Re: [HACKERS] Re: Beta2 ... ?
What I am gathering from all this conversation is that there is no repository for packages. Whoops. There is a repository for packages on ftp.postgresql.org, and you are welcome to contribute packages to there. As Peter points out, we probably aren't helping folks if we have some independent track of package development, so we would do better to also coordinate with the distro package maintainers at the same time. And we would all really prefer if the packages posted on ftp.postgresql.org are traceable to the "official" builds of packages elsewhere. For most folks running a particular OS and distro, there are certain places they would look for packages, and it would be great if those usual places have the benefit of your contributions too. For cases where more coordination is required, such as with the RPM packaging used for a bunch of distros, having them posted on ftp.postgresql.org has helped us keep the RPM package itself consistant with the various packagers. Not sure if you will find the same coordination problem with your platform. Well, in the light of the openpackages.org effort it seems you have just signed yourself up to create a BSD-independent package. ;-) Asking the relevant maintainer might be a first step, though. :) - Thomas
RPMs (was Re: [HACKERS] Re: Beta2 ... ?)
Lamar Owen writes: Does the python build stuff use DESTDIR these days? It does not. You'd have to delve into the internals of the Python-provided makefiles. I might just have to do that, but if you want to look then let me know because this should get fixed. The perl stuff needs some other things, unfortunately. I need to look in the CPAN RPM spec's to get examples of how to do this portably without major connarptions. The Perl build hasn't changed since 7.0 in dramatic ways. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: Beta2 ... ?
Speaking of which.. rpm -ivh ftp://ftp.postgresql/pub/whatever/postgresql-\*.rpm Is there a clearing house for packages? I have made some for OpenBSD (www.crimelabs.net/postgresql.shtml), but I wouldn't even know where to get the rpm or deb files. Should there be a folder on the ftp server for packages for the betas? - Brandon b. palmer, [EMAIL PROTECTED] pgp: www.crimelabs.net/bpalmer.pgp5
Re: [HACKERS] Re: Beta2 ... ?
bpalmer writes: Is there a clearing house for packages? I have made some for OpenBSD (www.crimelabs.net/postgresql.shtml), but I wouldn't even know where to get the rpm or deb files. Should there be a folder on the ftp server for packages for the betas? The RPMs are on the FTP server. In general I feel that packaging is left up to the operating system distributor. So your OpenBSD packages should be sent to the respective port maintainer. The RPMs are treated somewhat differently because they are platform independent and a lot of people are interested in getting betas in RPM form -- and not least importantly also because someone has taken the time to do it on a regular basis. The RPMs that are on the various Linux distribution CDs are still customized by the respective vendor. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Re: Beta2 ... ?
Is there a clearing house for packages? I have made some for OpenBSD (www.crimelabs.net/postgresql.shtml), but I wouldn't even know where to get the rpm or deb files. Should there be a folder on the ftp server for packages for the betas? The RPMs are on the FTP server. In general I feel that packaging is left up to the operating system distributor. So your OpenBSD packages should be sent to the respective port maintainer. The RPMs are treated somewhat differently because they are platform independent and a lot of people are interested in getting betas in RPM form -- and not least importantly also because someone has taken the time to do it on a regular basis. The RPMs that are on the various Linux distribution CDs are still customized by the respective vendor. Although packages should of course be sent to the port maintainer, I'm sure that in general that they would be welcome on ftp.postgresql.org also. The RPMs have greater visibility because we have taken the time to evolve the packaging (and because the packaging needed a good bit of work on the system I had at the time, so what the heck ;) and certainly they have benefited from Lamar's attention over the last months. Other packages would potentially be in the same circumstances: if they are packaged by someone familiar with the package itself, they will become better than if they are packaged by someone only familiar with packaging. Certainly every package done by someone active on these lists (e.g. Oliver with Debian) is of high quality and has benefited from their knowledge of PostgreSQL. I'm not sure what the case is for OpenBSD specifically, but you may want to talk more with the "official maintainer" if that isn't yourself... - Thomas
Re: [HACKERS] Re: Beta2 ... ?
bpalmer wrote: Is there a clearing house for packages? I have made some for OpenBSD (www.crimelabs.net/postgresql.shtml), but I wouldn't even know where to get the rpm or deb files. Should there be a folder on the ftp server for packages for the betas? Typically, deb files are obtained from ftp.debian.org or one of its mirrors. That's how you know you're getting an official Debian package. I'm in the process of making debs for the current beta, and will host them somewhere for people to grab for experimenting. I won't put anything into the Debian site until 7.1 is finally released. I'll announce where to get beta debs when the first set is done. However, that may be a day or two yet, because I have to redo a lot of packaging. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "For the LORD is good; his mercy is everlasting; and his truth endureth to all generations." Psalms 100:5
Re: [HACKERS] Re: Beta2 ... ?
bpalmer writes: This traffic does not seem necessary for the list, but here are my thoughts. I think it is. I don't begin to disagree with this for a second. I know that there are a lot of RPM users out there that would like the RPM. I'm aware that there would be a lesser demand for the OBSD packages, but it's still worth putting up there. Definitely. I have talked to the maintainer and am working with him on this. With luck, if I/we keep up on the betas, when 7.1 comes out for real, we will be able to make the changed then too. That's even better. Maintaining separate tracks of packages would be a source of confusion at best. What I am gathering from all this conversation is that there is no repository for packages. I would love to test the FBSD package too, but I don't know where it is, nor if it's being worked on. If it's not, I may be interested in working on that too! Well, in the light of the openpackages.org effort it seems you have just signed yourself up to create a BSD-independent package. ;-) Asking the relevant maintainer might be a first step, though. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: RPMs (was Re: [HACKERS] Re: Beta2 ... ?)
Peter Eisentraut wrote: Lamar Owen writes: Does the python build stuff use DESTDIR these days? It does not. You'd have to delve into the internals of the Python-provided makefiles. I might just have to do that, but if you want to look then let me know because this should get fixed. Hmmm. Then I may just keep the python build I have now, as it should still work, and it is a 'full-manual' build. The perl stuff needs some other things, unfortunately. I need to look in the CPAN RPM spec's to get examples of how to do this portably without major connarptions. The Perl build hasn't changed since 7.0 in dramatic ways. Well, it's pretty dramatic to get the starred box saying that I don't have permissions to install to where I want to install it when I'm running as root. Or, to put it more tersely, the 7.0 build worked in the RPM build context -- the 7.1 build does not with the same build technique. The root cause is an if [ -w check for the intalldir, which is set to an entirely inappropriate place. So, there are differences (I think the new way is going to be smoother, personally, once I get it working again). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: RPMs (was Re: [HACKERS] Re: Beta2 ... ?)
Lamar Owen writes: It's pretty dramatic to get the 'You don't have permissions to install' message from the perl 'make install' when I am performing the build (and the make install) as root. Particularly when 7.0's perl 'make install' worked semi-properly. I say semi-properly because the packing list had to be rewritten -- but at least the install did its job to the proper build-root'ed location. Then we apparently have a problem here. I can only say "works here", and I verified against the MakeMaker internals that things work as designed. What does 'gmake -f Makefile echo-installdir' show? Is it the location you'd expect, and do you really have write access to that location? Maybe a shell problem in GNUmakefile? I'm sitting at a RH 7.0 system and when I wrote this code I was using 5.2, so I must suspect that you are doing something that voids the warranty. ;-) -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: Beta2 ... ?
Lamar Owen writes: However, there are some hard-coded paths left in the build, and the perl client is being difficult, The Perl and Python clients use their own build system. Not sure how to handle it. and odbcinst is going to the REAL /usr/etc instead of $RPM_BUILD_ROOT/etc Works here. Hmm, are you using 'make install DESTDIR=/random/place'? Given that it's not documented it's unlikely that you are. But do start using it. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: Beta2 ... ?
Lamar Owen writes: Hmm, are you using 'make install DESTDIR=/random/place'? Given that it's not documented it's unlikely that you are. But do start using it. Enlighten me. DESTDIR does? It installs files at a different place than where they will eventually reside. E.g., if your --prefix is /usr/local and DESTDIR=/var/tmp/foo then the files will end up in /var/tmp/foo/usr/local. This is exactly for package management type applications. Currently, my install lines look like: make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr -C src install make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr -C src/interface s/perl5 install Then it's not surprising that things don't work since neither POSTGRESDIR nor PREFIX are used anywhere in PostgreSQL makefiles. So, I would put something like: make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr DESTDIR=/usr -C src install ??? ./configure --prefix=/usr --sysconfdir=/etc \ --docdir=/usr/share/doc/postgresql-'$(VERSION)' \ --mandir=/usr/share/man \ ...other options... make all make install DESTDIR=$RPM_BUILD_ROOT -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: Beta2 ... ?
Peter Eisentraut wrote:
Lamar Owen writes:
Enlighten me. DESTDIR does?
It installs files at a different place than where they will eventually
reside. E.g., if your --prefix is /usr/local and DESTDIR=/var/tmp/foo
then the files will end up in /var/tmp/foo/usr/local. This is exactly for
package management type applications.
Good.
Then it's not surprising that things don't work since neither POSTGRESDIR
nor PREFIX are used anywhere in PostgreSQL makefiles.
Had they been prior to 7.1?
./configure --prefix=/usr --sysconfdir=/etc \
--docdir=/usr/share/doc/postgresql-'$(VERSION)' \
--mandir=/usr/share/man \
...other options...
Already doing all of that, except --sysconfdir and friends. It's more
complicated than the above:
./configure --prefic=/usr --sysconfdir=/etc \
--docdir=%{_docdir}/%{name}/%{version} \
--mandir=%{_mandir} \
to take into account the differing distributions' differing ideas of
where things ought to be put.
make all
make install DESTDIR=$RPM_BUILD_ROOT
Much simpler. Will get back as soon as I get time to run a build (staff
meeting here in ten minutes.).
Does the python build stuff use DESTDIR these days? The perl stuff
needs some other things, unfortunately. I need to look in the CPAN RPM
spec's to get examples of how to do this portably without major
connarptions.
I knew you had changed something along those lines; I even remember a
message listing the switches necessary; but I could not find it in my
message archive.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Re: [HACKERS] Re: Beta2 ... ?
On Fri, 5 Jan 2001, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I am inclined to wait until a Release Candidate, if we have one this go around, is available before releasing RPM's, but my mind can be changed :-) Please do make beta RPMs available. Seems to me that there's a fair-size population of potential beta testers that we're shutting out of the process if we don't put out RPMs. Losing available beta testing work is not a good project management practice ... FWIW: We would definately beta test 7.1 beta releases on our test machines if RPMS were made available. However, if rpms are not made available, its unlikely that anyone around here will get time to build the sources from scratch. So you can count me as one beta tester that you would have if you made RPMS of the betas. Regards, Mike
Re: [HACKERS] Re: Beta2 ... ?
Michael J Schout wrote: We would definately beta test 7.1 beta releases on our test machines if RPMS were made available. However, if rpms are not made available, its unlikely that anyone around here will get time to build the sources from scratch. So you can count me as one beta tester that you would have if you made RPMS of the betas. Your offer is appreciated, and will most definitely be taken :-). I'm experiencing some degree of difficulty with the build -- mostly due to some reorg in the Perl and Python clients, but also some main Make framework as well, thanks to the RPM build-root environment. The compiles I have done outside the RPM environment have worked and installed (as source installs) very cleanly -- but the RPM build-root environment is rather different -- installing files to a location where they won't actually be installed to :-). Let me explain: so that RPM builders don't accidentally trash their systems during building, RPM includes a 'build-root' mechanism that allows a fake root for the build install to be used instead of the real root. Think 'chroot-lite'. This build-root is not enforced anywhere except by the spec file build and install sections. This also allows RPMs to be built for root installation by a non-root user, which provides an extra layer of filesystem protection. So, files get installed to this build-root, for eventual real installation on the real root when the RPM is actually installed. However, there are some hard-coded paths left in the build, and the perl client is being difficult, and odbcinst is going to the REAL /usr/etc instead of $RPM_BUILD_ROOT/etc I have lots of combing to do. In many ways 7.1 is an easier build -- but not in this regard. But I consider this an RPM issue and not a PostgreSQL tarball issue, meaning, while I will be developing patches for the RPM build, I won't expect those to be integrated into the main tarball. So, I'm plugging at it -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Beta2 ... ?
Emmanuel Charpentier wrote: Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I am inclined to wait until a Release Candidate, if we have one this go around, is available before releasing RPM's, but my mind can be changed :-) Please do make beta RPMs available. Seems to me that there's a fair-size population of potential beta testers that we're shutting out of the process if we don't put out RPMs. Losing available beta testing work is not a good project management practice ... I'd like to argue for .deb Debian packages as well, for similar reasons. But I'm aware that those are harder to produce, and that Oliver Elphick is almost alone on this task. I'll be doing it soon; but I don't want to release debs until there is no more chance of an initdb's being needed between betas; that bit me on 7.0. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Blessed are the pure in heart, for they shall see God."Matthew 5:8
Re: [HACKERS] Re: Beta2 ... ?
"Oliver Elphick" [EMAIL PROTECTED] writes: I'll be doing it soon; but I don't want to release debs until there is no more chance of an initdb's being needed between betas; that bit me on 7.0. In that case you may as well say that there will be no beta debs, and Debian users can forget about being part of the beta test process. We do not make a guarantee of "no more initdbs" until final release. The severity of bug needed to make us do one goes up considerably with each beta, but there will not be a guarantee on *any* beta. If there were such a guarantee, it'd be final not beta. regards, tom lane
Re: [HACKERS] Re: Beta2 ... ?
Oliver Elphick wrote: Emmanuel Charpentier wrote: Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I am inclined to wait until a Release Candidate, if we have one this go around, is available before releasing RPM's, but my mind can be changed :-) Please do make beta RPMs available. Seems to me that there's a fair-size population of potential beta testers that we're shutting out of the process if we don't put out RPMs. Losing available beta testing work is not a good project management practice ... I'd like to argue for .deb Debian packages as well, for similar reasons. But I'm aware that those are harder to produce, and that Oliver Elphick is almost alone on this task. I'll be doing it soon; but I don't want to release debs until there is no more chance of an initdb's being needed between betas; that bit me on 7.0. Well, it bit me too -- which is one of the lesser reasons why I have been reluctant to release RPM's before a release candidate. However, if someone wants to beta test the packaging (which, incidentally, is made substantially easier with 7.1) of the new release, then they should expect the results -- for instance, Red Hat doesn't guarantee that you will be able to upgrade from their public beta test OS releases to any future release (more than likely you _will_ be able to, but not necessarily). Only official releases are 'upgradeable'. I would suggest, as I am doing myself, to release beta-grade packages for testing _only_, with the proper disclaimers. But, I don't see how debs are harder to produce than RPMs -- and while I do have some help from RedHat, SuSE, and others, that help seems to be more towards their distribution rather than towards PostgreSQL -- ie, they go their own way for the most part. Each distribution using RPM's has its own arcane rules -- and some of those rules make little sense from the PostgreSQL point of view. And, I don't blame them one whit for that -- they are, after all, employed for the purpose of making a distribution, not a PostgreSQL package. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Beta2 ... ?
On Fri, 5 Jan 2001, Lamar Owen wrote: Ok, consider my mind changed. :-). My only concerns were, due to some feedback I have gotten, is that people would treat the RPM release as _productions_ rather than beta -- but maybe I'm just being paranoid. Just because you're paranoid doesn't mean someone isn't out to get you! But like Tom says - a beta in the name - should do it (and will for me). Lamar, Is it possible to put some variables in the spec file so I can turn off compiling the python and tcl portions. Of course I seem to remember a thread to a similar effect floating through but can't remember what the outcome was. TIA, Rod --
Re: [HACKERS] Re: Beta2 ... ?
Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I am inclined to wait until a Release Candidate, if we have one this go around, is available before releasing RPM's, but my mind can be changed :-) Please do make beta RPMs available. Seems to me that there's a fair-size population of potential beta testers that we're shutting out of the process if we don't put out RPMs. Losing available beta testing work is not a good project management practice ... I'd like to argue for .deb Debian packages as well, for similar reasons. But I'm aware that those are harder to produce, and that Oliver Elphick is almost alone on this task. -- Emmanuel Charpentier
[HACKERS] Re: Beta2 ... ?
The Hermit Hacker [EMAIL PROTECTED] writes: Anyone have anything outstanding that prevents me rolling a Beta2 and announcing it this weekend? Tom? Vadim? Peter? Wrap it up, I'd say. I don't have anything pending that seems worth holding up beta2 for. Will RPM's be made availiable for this beta release? Mike
Re: [HACKERS] Re: Beta2 ... ?
mike wrote: Tom Lane Wrote: Wrap it up, I'd say. I don't have anything pending that seems worth holding up beta2 for. Will RPM's be made availiable for this beta release? I intend to do so, but it will be a few days to a week after the tarball release. I am inclined to wait until a Release Candidate, if we have one this go around, is available before releasing RPM's, but my mind can be changed :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Beta2 ... ?
Lamar Owen [EMAIL PROTECTED] writes: I am inclined to wait until a Release Candidate, if we have one this go around, is available before releasing RPM's, but my mind can be changed :-) Please do make beta RPMs available. Seems to me that there's a fair-size population of potential beta testers that we're shutting out of the process if we don't put out RPMs. Losing available beta testing work is not a good project management practice ... regards, tom lane
Re: [HACKERS] Re: Beta2 ... ?
Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I am inclined to wait until a Release Candidate, if we have one this go around, is available before releasing RPM's, but my mind can be changed :-) Please do make beta RPMs available. Seems to me that there's a fair-size population of potential beta testers that we're shutting out of the process if we don't put out RPMs. Losing available beta testing work is not a good project management practice ... Ok, consider my mind changed. :-). My only concerns were, due to some feedback I have gotten, is that people would treat the RPM release as _productions_ rather than beta -- but maybe I'm just being paranoid. More than likely I'm being paranoid. Look for RPM's in a few days, then. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
