Thread

1. Re: [HACKERS] Perl library (was Building Postgres)

   Tom Lane <tgl@sss.pgh.pa.us> — 1999-06-29T02:04:08Z

   Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
   > ... Assuming that the code generated is a bit
   > more tolerant of version changes in perl,
   
   I believe that's nearly as risky as hardwiring the install path.
   For example, we already know that the existing perl5 interface
   *source* code is broken for the latest Perl releases (5.005something),
   nevermind trying to make the object code compatible.  (I'm going
   to try to figure out whether we can tweak the source to work under
   either version ... it may take conditional compilation :-( ... if
   anyone else is in a bigger hurry than me, be my guest ...)
   
   > One possibility is to
   > simply lift all of the perl5 source tree into the rpm, and actually do
   > the build on the target machine from scratch. afaik, this is *not* the
   > preferred style for rpms.
   
   It may be swimming upstream in the RPM culture, but it should work
   and work reliably.  *Not* doing the expected configuration on the
   target machine will be swimming upstream in the Perl culture, and
   I'll wager that the undertow is a lot more dangerous in that case.
   
   			regards, tom lane
   
   

2. Re: [HACKERS] Perl library (was Building Postgres)

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-06-29T04:57:07Z

   > It may be swimming upstream in the RPM culture, but it should work
   > and work reliably.  *Not* doing the expected configuration on the
   > target machine will be swimming upstream in the Perl culture, and
   > I'll wager that the undertow is a lot more dangerous in that case.
   
   Yup. I'll probably end up trying to package all of the source code
   into the binary rpms, with an install script. But I think my first cut
   will try to force the generated files into the correct place. I've got
   lots of other interfaces to handle, and want to get the rpms out as a
   beta trial asap.
   
   We'll see how long it takes someone to break the rpm :/
   
                       - Thomas
   
   -- 
   Thomas Lockhart				lockhart@alumni.caltech.edu
   South Pasadena, California
   
   

3. Re: [HACKERS] Perl library (was Building Postgres)

   Brian E Gallew <geek+@cmu.edu> — 1999-06-29T14:49:26Z

   Then <lockhart@alumni.caltech.edu> spoke up and said:
   > 
   > > It may be swimming upstream in the RPM culture, but it should work
   > > and work reliably.  *Not* doing the expected configuration on the
   > > target machine will be swimming upstream in the Perl culture, and
   > > I'll wager that the undertow is a lot more dangerous in that case.
   > 
   > Yup. I'll probably end up trying to package all of the source code
   > into the binary rpms, with an install script. But I think my first cut
   > will try to force the generated files into the correct place. I've got
   > lots of other interfaces to handle, and want to get the rpms out as a
   > beta trial asap.
   
   Wouldn't it be better to create a CPAN package and distribute it from
   *there*?  I realize that this method has the problem that package
   updates and PostgreSQL updates could become desynchronized, but I
   think this would address the issue adequately.
   
   -- 
   =====================================================================
   | JAVA must have been developed in the wilds of West Virginia.      |
   | After all, why else would it support only single inheritance??    |
   =====================================================================
   | Finger geek@cmu.edu for my public key.                            |
   =====================================================================
   

4. Re: [HACKERS] Perl library (was Building Postgres)

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-06-29T15:28:08Z

   > Wouldn't it be better to create a CPAN package and distribute it from
   > *there*?  I realize that this method has the problem that package
   > updates and PostgreSQL updates could become desynchronized, but I
   > think this would address the issue adequately.
   
   Well, the problem I'm trying to solve is rpm packaging, which is not
   necessarily the same as solving the perl distribution issue.
   However...
   
   Would a CPAN package be more amenable to an rpm packaging? That is, if
   we had a CPAN distribution (generated locally, of course), could I
   plop that into an rpm and have a standard, easy procedure to follow
   within the rpm to get the stuff extracted and installed onto a
   machine?? I'm blissfully ignorant about CPAN and the packaging
   conventions, but would like suggestions.
   
                     - Thomas
   
   -- 
   Thomas Lockhart				lockhart@alumni.caltech.edu
   South Pasadena, California