Thread: Beta2 ... ?
Anyone have anything outstanding that prevents me rolling a Beta2 and
announcing it this weekend? Tom? Vadim? Peter?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> Anyone have anything outstanding that prevents me rolling a Beta2 and > announcing it this weekend? Tom? Vadim? Peter? I'll commit small changes to xlog.c today. Vadim
The Hermit Hacker <scrappy@hub.org> 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.
regards, tom lane
> The Hermit Hacker <scrappy@hub.org> 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
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
Lamar Owen <lamar.owen@wgcr.org> 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
Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> 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
Lamar Owen <lamar.owen@wgcr.org> writes:
> 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.
As long as the RPMs are clearly marked beta, I don't have a lot of
sympathy for anyone who thinks beta == production.
regards, tom lane
The Hermit Hacker writes: > Anyone have anything outstanding that prevents me rolling a Beta2 and > announcing it this weekend? Tom? Vadim? Peter? I'll commit the grammar changes we discussed yesterday, plus some new documentation that goes with it, tomorrow. I'm also going to send you a patch for mk-release so that the right documentation files are shipped this time. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
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 --
Tom Lane wrote: > > Lamar Owen <lamar.owen@wgcr.org> 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
Emmanuel Charpentier wrote: >Tom Lane wrote: >> >> Lamar Owen <lamar.owen@wgcr.org> writes: >> > I am inclined to wait untila 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 potentialbeta testers that we're shutting >> out of the process if we don't put out RPMs. Losing available beta >> testingwork is not a good project management practice ... > >I'd like to argue for .deb Debian packages as well, for similarreasons. >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 Oliver.Elphick@lfix.co.uk 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
"Oliver Elphick" <olly@lfix.co.uk> 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
Oliver Elphick wrote: > Emmanuel Charpentier wrote: > >Tom Lane wrote: > >> Lamar Owen <lamar.owen@wgcr.org> 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
On Fri, 5 Jan 2001, Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> 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
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
Michael J Schout writes: > 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. Building from source takes five minutes. Reading the installation instructions takes maybe ten minutes. Don't tell me you don't have that amount of time but you still want to beta test. *shrug* -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
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 peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut wrote: > 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. I'm looking, in between day job stuff. > > and odbcinst is going to the REAL /usr/etc instead of > > $RPM_BUILD_ROOT/etc.... > Works here. Which doesn't surprise me. The RPM building environment is not the same as building from source inside a regular user shell. Similar, but not the same. > 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? 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 So, I would put something like: make POSTGRESDIR=$RPM_BUILD_ROOT/usr PREFIX=$RPM_BUILD_ROOT/usr DESTDIR=/usr -C src install ??? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
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 peter_e@gmx.net http://yi.org/peter-e/
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
On Wed, 10 Jan 2001, Peter Eisentraut wrote: > Michael J Schout writes: > > > 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. > > Building from source takes five minutes. Reading the installation > instructions takes maybe ten minutes. Don't tell me you don't have that > amount of time but you still want to beta test. *shrug* Yes, building the sources isn't that difficult, but it definately takes longer than: rpm -ivh ftp://ftp.postgresql/pub/whatever/postgresql-\*.rpm My feeling is that if we can make it as easy as possible for beta testers to get the beta releases up and running, the more likely they are to use the beta releases. Mike
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 peter_e@gmx.net http://yi.org/peter-e/
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, bpalmer@crimelabs.net pgp: www.crimelabs.net/bpalmer.pgp5
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 peter_e@gmx.net http://yi.org/peter-e/
> > 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
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 folderon 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 Oliver.Elphick@lfix.co.uk 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 toall generations." Psalms 100:5
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 peter_e@gmx.net http://yi.org/peter-e/
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
Oliver Elphick wrote: > because I have to redo a lot of packaging. I know how you feel.....:-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen wrote: > 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. You'd think that, as a native English speaker, I could structure a sentence more effectively than that.... Let me rephrase: 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. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
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 peter_e@gmx.net http://yi.org/peter-e/
> > 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
> 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.
Just an fyi...
I have been having trouble with one of the package files disappearing
from the temporary instllation area during the rpm build of pg-7.0.3 for
Mandrake on Mandrake-7.2 using a recent source RPM. I haven't tracked
down the problem yet :(
- Thomas
On Sat, 13 Jan 2001, Thomas Lockhart wrote: > > 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 > I have been having trouble with one of the package files disappearing > from the temporary instllation area during the rpm build of pg-7.0.3 for > Mandrake on Mandrake-7.2 using a recent source RPM. I haven't tracked > down the problem yet :( To say that I am interested in the outcome would be an understatement. I fixed my perl problems by invoking the Makefile (not the GNUmakefile) for the second install and setting PREFIX properly then. Yes, the second install phase. I'll see if I can't fix this a little better -- but my goal was to get a build so that I can start fixing some things. Most of the stuff I am having to 'fix' is kludgery that Peter's config and makefile changes are eliminating :-). But having to regen patches and rebuild from scratch each time I change the spec makes it time-consuming..... But the single DESTDIR addition makes it a much easier and cleaner build -- Lamar Owen WGCR Internet Radio 1 Peter 4:11