Обсуждение: SuSE RPMs available for PostgreSQL 7.4
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
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 #
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
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
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
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
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
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
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
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 ...
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 ...
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
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
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
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
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
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