Thread: SuSE RPMs available for PostgreSQL 7.4

SuSE RPMs available for PostgreSQL 7.4

From
Peter Eisentraut
Date:
SuSE RPMs for PostgreSQL 7.4 are available at

    ftp://ftp.postgresql.org/pub/binary/v7.4/suse

or a mirror

    http://www.postgresql.org/mirrors-www.html

or at

    ftp://ftp.suse.com/pub/people/max/postgresql-7.4

or a mirror

    http://www.suse.com/us/private/download/ftp/int_mirrors.html
    http://www.suse.com/us/private/download/ftp/germ_mirrors.html

--
Peter Eisentraut   peter_e@gmx.net


Re: SuSE RPMs available for PostgreSQL 7.4

From
Jan Wieck
Date:
Peter Eisentraut wrote:

> SuSE RPMs for PostgreSQL 7.4 are available at
>
>     ftp://ftp.postgresql.org/pub/binary/v7.4/suse
>
> or a mirror
>
>     http://www.postgresql.org/mirrors-www.html
>
> or at
>
>     ftp://ftp.suse.com/pub/people/max/postgresql-7.4

Isn't there a "v" missing here?

>
> or a mirror
>
>     http://www.suse.com/us/private/download/ftp/int_mirrors.html
>     http://www.suse.com/us/private/download/ftp/germ_mirrors.html
>


--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


Re: SuSE RPMs available for PostgreSQL 7.4

From
Lamar Owen
Date:
On Monday 17 November 2003 05:18 pm, Peter Eisentraut wrote:
> SuSE RPMs for PostgreSQL 7.4 are available at
>     ftp://ftp.postgresql.org/pub/binary/v7.4/suse

Hey, Peter, for one who consistently complains about lack of consistency in
naming, you completely diregarded the precedent that has previously been set
for naming RPM releases (regardless of the source).

And then you neglected to put group write permissions on the directory so that
other binaries could be uploaded.

So now I wouldn't be able to upload RPMs in the customary place.  Many thanks.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu


Re: SuSE RPMs available for PostgreSQL 7.4

From
Shridhar Daithankar
Date:
Jan Wieck wrote:

> Peter Eisentraut wrote:
>
>> SuSE RPMs for PostgreSQL 7.4 are available at
>>
>>     ftp://ftp.postgresql.org/pub/binary/v7.4/suse
>>
>> or a mirror
>>
>>     http://www.postgresql.org/mirrors-www.html
>>
>> or at
>>
>>     ftp://ftp.suse.com/pub/people/max/postgresql-7.4
>
>
> Isn't there a "v" missing here?

Not again..

  Shridhar


Re: SuSE RPMs available for PostgreSQL 7.4

From
Lamar Owen
Date:
On Wednesday 19 November 2003 11:59 am, Peter Eisentraut wrote:
> Lamar Owen writes:
> > Hey, Peter, for one who consistently complains about lack of consistency
> > in naming, you completely diregarded the precedent that has previously
> > been set for naming RPM releases (regardless of the source).

> These are SuSE RPMs.  They were build by SuSE following the conventions
> that SuSE has used for their past releases.  So who are we to argue with
> that?

The place they were put.  The 'customary place' has been
v{version}/RPMS/{distribution} so that they would be in
pub/binary/v7.4/RPMS/suse-{version}.  Their source RPM would go there too.  I
have no problem with the name of the RPM's themselves, just where they were
put.  As long as they don't have a PGDG in the release tag I'm happy with the
package names.

> > And then you neglected to put group write permissions on the directory so
> > that other binaries could be uploaded.

> I see

> drwxrwxr-x  3 petere  pgsql  512 Nov 17 20:47 binary/v7.4/
> If someone else put the group write permissions in there in between, I
> apologize.

I asked Marc to do it.

I would kindof liked a heads up on this; I had some plans for the RPMset that
I'm now going to delay.  But it is good for SuSE users to have something
there now, I agree.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu


Re: SuSE RPMs available for PostgreSQL 7.4

From
Peter Eisentraut
Date:
Lamar Owen writes:

> Hey, Peter, for one who consistently complains about lack of consistency in
> naming, you completely diregarded the precedent that has previously been set
> for naming RPM releases (regardless of the source).

These are SuSE RPMs.  They were build by SuSE following the conventions
that SuSE has used for their past releases.  So who are we to argue with
that?

> And then you neglected to put group write permissions on the directory so that
> other binaries could be uploaded.

I see

drwxrwxr-x  3 petere  pgsql  512 Nov 17 20:47 binary/v7.4/

If someone else put the group write permissions in there in between, I
apologize.

> So now I wouldn't be able to upload RPMs in the customary place.  Many thanks.

What is the customary place?  I'm confused.

--
Peter Eisentraut   peter_e@gmx.net


Re: SuSE RPMs available for PostgreSQL 7.4

From
Peter Eisentraut
Date:
Lamar Owen writes:

> The place they were put.  The 'customary place' has been
> v{version}/RPMS/{distribution} so that they would be in
> pub/binary/v7.4/RPMS/suse-{version}.  Their source RPM would go there too.

My reverse engineering attempt at the existing custom went as follows:

I saw

SRPMS        containing a source RPM
distrib-1    above source RPM built for that distribution
distrib-2    above source RPM built for that distribution

So since this RPM set uses a different source RPM, one solution would have
been

SRPMS        containing more than one source RPM
distrib-1    one of the above source RPMs built for that distribution
distrib-2    one of the above source RPMs built for that distribution

But that seems unnecessarily confusing.

You seem to propose this solution:

SRPMS        containing a source RPM
distrib-1    above source RPM built for that distribution
distrib-2    above source RPM built for that distribution
other-distrib    containing different source RPM and binary RPM

But that is assymetric.

So the solution was to put each RPM set, consisting of a source RPM and
binaries built from it, in its own subdirectory.

That solution also has the advantage that if someone wanted to post other
binaries, say for Debian or Solaris, they could become a peer directory of
"suse".  That way, someone looking for binaries could follow the name of
the operating system and would not have to know details about which
packaging system is used.

--
Peter Eisentraut   peter_e@gmx.net


Re: SuSE RPMs available for PostgreSQL 7.4

From
Lamar Owen
Date:
On Wednesday 19 November 2003 12:49 pm, Peter Eisentraut wrote:
> Lamar Owen writes:
> > The place they were put.  The 'customary place' has been
> > v{version}/RPMS/{distribution} so that they would be in
> > pub/binary/v7.4/RPMS/suse-{version}.  Their source RPM would go there
> > too.

> SRPMS        containing a source RPM
> distrib-1    above source RPM built for that distribution
> distrib-2    above source RPM built for that distribution
> other-distrib    containing different source RPM and binary RPM

> But that is assymetric.

Yes, it is.  However, it has been done before when it made sense to do so.

> So the solution was to put each RPM set, consisting of a source RPM and
> binaries built from it, in its own subdirectory.

That solution has the disadvantage of either storing multiple identical source
RPM's or maintaining multiple links to the single source RPM.  There will be
a fedora-core-1, a redhat-9, and redhat-8.0, a redhat-7.3, an aurora-1.0, and
possibly a redhat-6.2 that will hopefully use the single source RPM.  Now I
can maintain links to the single one, or I can waste 10MB of space per
distribution.  But I didn't do it that way, putting the 'canonical' source
RPM into a separate SRPMS dir, since the idea of the single source RPM was to
be distribution-independent.

> That solution also has the advantage that if someone wanted to post other
> binaries, say for Debian or Solaris, they could become a peer directory of
> "suse".  That way, someone looking for binaries could follow the name of
> the operating system and would not have to know details about which
> packaging system is used.

There are advantages to that, I'll admit.  However, one could have an RPM for
Solaris, for instance, in addition to the regualr Solaris packages, since RPM
will install on Solaris.  Debian packages haven't historically been stored on
ftp.postgresql.org.  Win32 binaries have been put alongside the RPMS
directory before.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu


Re: SuSE RPMs available for PostgreSQL 7.4

From
Peter Eisentraut
Date:
Lamar Owen writes:

> > But that is assymetric.
>
> Yes, it is.  However, it has been done before when it made sense to do so.

It would imply that there is some general or master SRPM and the other
ones are alternative versions.  So people looking for a SRPM would easily
be led to download the wrong one.  In fact, they are parallel variants, so
a parallel directory structure seems right to me.

Another problem is that changing the directory layout would make the
automatic mirroring impossible.

> That solution has the disadvantage of either storing multiple identical source
> RPM's or maintaining multiple links to the single source RPM.  There will be
> a fedora-core-1, a redhat-9, and redhat-8.0, a redhat-7.3, an aurora-1.0, and
> possibly a redhat-6.2 that will hopefully use the single source RPM.  Now I
> can maintain links to the single one, or I can waste 10MB of space per
> distribution.

So why don't you do

binary/redhat/
    SRPMS
    fedora-this
    redhat-that

> But I didn't do it that way, putting the 'canonical' source RPM into a
> separate SRPMS dir, since the idea of the single source RPM was to be
> distribution-independent.

Realistically, a distribution independent source RPM is unrealistic.  It's
a bit sad, but the market has decided.

--
Peter Eisentraut   peter_e@gmx.net


Re: SuSE RPMs available for PostgreSQL 7.4

From
"Marc G. Fournier"
Date:
On Wed, 19 Nov 2003, Lamar Owen wrote:

> On Wednesday 19 November 2003 11:59 am, Peter Eisentraut wrote:
> > Lamar Owen writes:
> > > Hey, Peter, for one who consistently complains about lack of consistency
> > > in naming, you completely diregarded the precedent that has previously
> > > been set for naming RPM releases (regardless of the source).
>
> > These are SuSE RPMs.  They were build by SuSE following the conventions
> > that SuSE has used for their past releases.  So who are we to argue with
> > that?
>
> The place they were put.  The 'customary place' has been
> v{version}/RPMS/{distribution} so that they would be in
> pub/binary/v7.4/RPMS/suse-{version}.  Their source RPM would go there
> too.  I have no problem with the name of the RPM's themselves, just
> where they were put.  As long as they don't have a PGDG in the release
> tag I'm happy with the package names.

Actually, ummm ... what if I were to upload FreeBSD binaries?  I think:

/pub/binary/v7.4/{suse|redhat|freebsd|solaris} makes more sense, no?

the RPMS at the top directory made sense when it was only RPMS that were
being provided, but ...

Re: SuSE RPMs available for PostgreSQL 7.4

From
"Marc G. Fournier"
Date:
On Wed, 19 Nov 2003, Peter Eisentraut wrote:

> So why don't you do
>
> binary/redhat/
>     SRPMS
>     fedora-this
>     redhat-that

peter and I agree *sooooo* often, but I do agree with him on this one ...
I'd love to see someone submit binaries for, say, the various version of
solaris, and the current dir hierachy doesn't seem to 'flow' for doing
multiple OS distributions ...

As lamar says, Solaris can do rpm's, but why, when it has pkg_add ...

Re: SuSE RPMs available for PostgreSQL 7.4

From
Lamar Owen
Date:
On Wednesday 19 November 2003 01:29 pm, Peter Eisentraut wrote:
> It would imply that there is some general or master SRPM and the other
> ones are alternative versions.

Read the spec file for the SuSE RPM.  Then reply.  Even Reinhard refers to the
one SRPM I upload as being the 'official' SRPM.  Yes, there is a general or
master SRPM, and it is our SRPM.

>  So people looking for a SRPM would easily
> be led to download the wrong one.  In fact, they are parallel variants, so
> a parallel directory structure seems right to me.

No, they are not parallel variants.  And I am clear in the wording I use in
the announcement that the user's distribution-distributed RPM should be used
unless there is a pressing need to do otherwise.  It has now been this way
for four years.  Our RPMset is as much for the distributions to use as a
template as it is for end users, and this has worked in practice fairly well
for four years.

My effort has been expended not in directly building for every distribution,
but for providing a starting point that the distributions can use and modify
to their heart's content.  By keeping the PGDG set in that role, the various
distributions have a common starting point, so at least postgresql works
pretty much the same way across distributions.  The copyright notices and
comments found, in Red Hat, SuSE's, and others RPM specfiles tell the tale to
all who care to read.

> Another problem is that changing the directory layout would make the
> automatic mirroring impossible.

Please explain.

> Realistically, a distribution independent source RPM is unrealistic.  It's
> a bit sad, but the market has decided.

I have made the source RPM be distribution independent before, for Great
Bridge.  A single source RPM built on SuSE, Red Hat, TurboLinux, Mandrake,
and Caldera.  The spec file was not very clean, but the system worked OK at
the time.  Given the time to do it, I could do it now.  Just don't have quite
the time, nor do I have the build farm that it requires (Great Bridge did,
and I used their build farm to do it).  Yes, it is hard to do it right.

So I've been down this road before.  FWIW, I've read Reinhard's spec file, and
it's pretty close to distribution independent now.  There are some macros he
uses I dont yet understand, but judicious use of conditional defines could
make another fully distribution independent source RPM, possibly building
from his work.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu


Re: SuSE RPMs available for PostgreSQL 7.4

From
Lamar Owen
Date:
On Wednesday 19 November 2003 01:43 pm, Marc G. Fournier wrote:
> On Wed, 19 Nov 2003, Peter Eisentraut wrote:
> > So why don't you do
> >
> > binary/redhat/
> >     SRPMS
> >     fedora-this
> >     redhat-that

> peter and I agree *sooooo* often, but I do agree with him on this one ...
> I'd love to see someone submit binaries for, say, the various version of
> solaris, and the current dir hierachy doesn't seem to 'flow' for doing
> multiple OS distributions ...

That would work, except for the fact the the RPM's are not just for Red Hat.
But, if the consensus of the list is to do it this way, then I'll maintain a
symlink structure (to keep from wasting space) that will implement this.  Is
this what the users want?

> As lamar says, Solaris can do rpm's, but why, when it has pkg_add ...

If a user has gone to the trouble to install RPM on Solaris, that that user is
probably going to want to use an RPM.

In the case of FreeBSD, isn't it the preference to use the ports system?

In the case of Debian, Oliver maintains his package inside of the Debian
system, and not on ftp.postgresql.org.  I don't want to waste
postgresql.org's disk space or bandwidth.

Or, to recast the question, do people think it's a good idea for PGDG to have
a 'canonical' general, master, source RPM to try to keep the various
RPM-based distributions using a common base for more consistent installs
(that become easier to support and troubleshoot)?  If the consensus is that
we should just let the distributions do all the work and maintain parallel
variants (hosted by their own servers), well, that's OK with me.  I can go
off to the Fedora Core people and volunteer to just keep up the Fedora Core
PostgreSQL RPM set, and forget about generic issues.  Or even let someone
else do it; Red Hat has their own internal maintainer that is quite capable
of doing the job.  Do I need to continue to do what I've been doing?  I
certainly want to continue, but if the effort isn't needed, well, I can put
my energies elsewhere, both inside the PostgreSQL project as well as outside.
I certainly have learned a great deal while doing this, and don't regret any
of it.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu


Re: SuSE RPMs available for PostgreSQL 7.4

From
Peter Eisentraut
Date:
Lamar Owen writes:

> Read the spec file for the SuSE RPM.  Then reply.  Even Reinhard refers to the
> one SRPM I upload as being the 'official' SRPM.  Yes, there is a general or
> master SRPM, and it is our SRPM.

"Official" is in the eye of the beholder.  If it's on a SuSE CD, then it's
official.  Everything else is just a series of coincidences.  You call
yours "official", so the SuSE spec file refers to them as such.  But in
fact, distributors build packages for their distributions and their
customers, so making them similar to other spec files is just a secondary
effect.

> My effort has been expended not in directly building for every distribution,
> but for providing a starting point that the distributions can use and modify
> to their heart's content.  By keeping the PGDG set in that role, the various
> distributions have a common starting point, so at least postgresql works
> pretty much the same way across distributions.  The copyright notices and
> comments found, in Red Hat, SuSE's, and others RPM specfiles tell the tale to
> all who care to read.

True, but you're under the misimpression that distributors always use your
set and then add on their things.  But development also flows the other
way.  So at any one point, one set is never a subset of the other.  So
there is no hierarchy.

> > Another problem is that changing the directory layout would make the
> > automatic mirroring impossible.
>
> Please explain.

The directory structure is a mirror of the SuSE FTP site.

--
Peter Eisentraut   peter_e@gmx.net


Re: SuSE RPMs available for PostgreSQL 7.4

From
Peter Eisentraut
Date:
Lamar Owen writes:

> In the case of FreeBSD, isn't it the preference to use the ports system?

The preference is to use the ports system once and then use the resulting
packages the subsequent times.

--
Peter Eisentraut   peter_e@gmx.net


Re: SuSE RPMs available for PostgreSQL 7.4

From
Lamar Owen
Date:
On Wednesday 19 November 2003 02:11 pm, Peter Eisentraut wrote:
> "Official" is in the eye of the beholder.  If it's on a SuSE CD, then it's
> official.  Everything else is just a series of coincidences.  You call
> yours "official", so the SuSE spec file refers to them as such.  But in
> fact, distributors build packages for their distributions and their
> customers, so making them similar to other spec files is just a secondary
> effect.

So Red Hat's use of the same is just a 'coincidence'.  Ok.

> > My effort has been expended not in directly building for every
> > distribution, but for providing a starting point that the distributions
> > can use and modify to their heart's content.  By keeping the PGDG set in
> > that role, the various distributions have a common starting point, so at
> > least postgresql works pretty much the same way across distributions.

> True, but you're under the misimpression that distributors always use your
> set and then add on their things.  But development also flows the other
> way.  So at any one point, one set is never a subset of the other.  So
> there is no hierarchy.

No, I'm not under any such misimpression.  And the set is 'our' set, not just
mine, since the group has thus far allowed the use of the postgresql.org
server for distribution.  I do not see the RPMs as just being 'mine' -- they
are the community's.  By having the PostgreSQL Global Development Group's
name, download site, and support behind this set means that they are
consisdered 'upstream' and the current feel, at least in the Red Hat niche,
is to use upstream whenever possible, and to refer bugs, patches, etc back
upstream whenever practical.  In this particular case, Red Hat employs
upstream developers (which is a common thing for Red Hat to do, as they
employ many upstream developers in many projects).  They do not empoy me; I
volunteer my time.

But, as I said in another post, if the community is of the consensus that
having the upstream RPM set is not a good thing, then I have no problem
letting the distributors do their own thing.  I just want to make things
easier for the users.

As to development flowing multiple directions, it's called cooperation.  Thus
far, most distributors have chosen to use things from our set, and I have
chosen to use things that were useful from their sets.  Would the same things
happen at the same level if our set did not exist?  This started in 1999
during the release cycle for Red Hat 6.1, when they chose to use the exact
same set I was working on at the time.  The exact set I had built was
distributed on the Red Hat CD for 6.1.  Was it built on others work?  Sure it
was.  Did it use good ideas from other people?  I am not a NIHilist, so it
certainly did.  Was it 'official' in any way?  Once I was allowed by PGDG to
upload it to the ftp.postgresql.org site, it became, in the view of the
PostgreSQL group, 'official' for the group.

Have I always done the best job?  Not necessarily.  Have the distributors'
RPMs differed from ours?  Yes, their needs and our needs differ.  Have they
synchronized to our set periodically?  Yes, they have.  Do they call our set
the 'official' set?  Yes, they do.

Why do you have a problem with this?

> The directory structure is a mirror of the SuSE FTP site.

On ftp.postgresql.org?  I'm only talking about ftp.postgresql.org.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu


Re: SuSE RPMs available for PostgreSQL 7.4

From
Peter Eisentraut
Date:
Lamar Owen writes:

> Why do you have a problem with this?

Development technicalities aside, when people go to the FTP site in search
for binaries, they primarily search for binaries for their operating
system.  So the operating system becomes the top directory hierarchy.
Why do you have a problem with this?

If you manage to build RPMs for several operating systems out of one
source RPM, great job.  But the above still applies.

> > The directory structure is a mirror of the SuSE FTP site.
>
> On ftp.postgresql.org?  I'm only talking about ftp.postgresql.org.

Yes.

--
Peter Eisentraut   peter_e@gmx.net