pg_filedump binary for CentOS
As far as I can see there is no pre-built pg_filedump binary for the
PDGD yum repository (8.3.11 for RHEL5). Before I embark on building it
from source I figured I'd ask here if I'm correct that there is no
binary hidden somewhere in the packages.
Thanks.
On Sep 27, 2010, at 9:47 AM, David Boreham wrote:
As far as I can see there is no pre-built pg_filedump binary for the PDGD yum repository (8.3.11 for RHEL5). Before I embark on building it from source I figured I'd ask here if I'm correct that there is no binary hidden somewhere in the packages.
Yes, you are right. pg_filedump is not part of PG Source. Its a separate module, which needs to be compile.
Thanks & Regards,
Vibhor Kumar
On Sun, 2010-09-26 at 22:17 -0600, David Boreham wrote:
As far as I can see there is no pre-built pg_filedump binary for the
PDGD yum repository (8.3.11 for RHEL5). Before I embark on building it
from source I figured I'd ask here if I'm correct that there is no
binary hidden somewhere in the packages.
Looks like package was lost during transition.
I am rebuilding it, and I'll let you know when I upload it.
Regards,
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
PostgreSQL RPM Repository: http://yum.pgrpms.org
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Looks like package was lost during transition.
I am rebuilding it, and I'll let you know when I upload it.
Regards,
-----
The voice input and output is very good in this
http://www.tomtop.com/black-ps3-wireless-bluetooth-headset-for-playstation-3.html?aid=z
Wireless PS3 Headset . It is compatible with all PS3 games.Buy from Reliable
http://www.tomtop.com/google-android-7-notebook-3g-tablet-pc-umpc-wifi-mid-pda.html?aid=z
Google Android PC apad Wholesalers.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/pg-filedump-binary-for-CentOS-tp2854791p2855181.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
On Sun, 2010-09-26 at 22:17 -0600, David Boreham wrote:
As far as I can see there is no pre-built pg_filedump binary for the
PDGD yum repository (8.3.11 for RHEL5). Before I embark on building it
from source I figured I'd ask here if I'm correct that there is no
binary hidden somewhere in the packages.
They are ready:
http://yum.pgrpms.org/8.3/redhat/rhel-5-x86_64/repoview/pg_filedump.html
http://yum.pgrpms.org/8.3/redhat/rhel-5.0-i386/repoview/pg_filedump.html
-HTH
Regards,
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
PostgreSQL RPM Repository: http://yum.pgrpms.org
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
On 9/27/2010 6:51 AM, Devrim GÜNDÜZ wrote:
They are ready:
http://yum.pgrpms.org/8.3/redhat/rhel-5-x86_64/repoview/pg_filedump.html
http://yum.pgrpms.org/8.3/redhat/rhel-5.0-i386/repoview/pg_filedump.html
Thanks !
David Boreham wrote:
As far as I can see there is no pre-built pg_filedump binary for the
PDGD yum repository (8.3.11 for RHEL5). Before I embark on building it
from source I figured I'd ask here if I'm correct that there is no
binary hidden somewhere in the packages.
[ CC to hackers.]
Should we consider moving pg_filedump into our /contrib?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Thu, Oct 14, 2010 at 12:41 PM, Bruce Momjian <bruce@momjian.us> wrote:
David Boreham wrote:
As far as I can see there is no pre-built pg_filedump binary for the
PDGD yum repository (8.3.11 for RHEL5). Before I embark on building it
from source I figured I'd ask here if I'm correct that there is no
binary hidden somewhere in the packages.[ CC to hackers.]
Should we consider moving pg_filedump into our /contrib?
If it's license-compatible, +1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Excerpts from Robert Haas's message of jue oct 14 14:10:57 -0300 2010:
On Thu, Oct 14, 2010 at 12:41 PM, Bruce Momjian <bruce@momjian.us> wrote:
David Boreham wrote:
As far as I can see there is no pre-built pg_filedump binary for the
PDGD yum repository (8.3.11 for RHEL5). Before I embark on building it
from source I figured I'd ask here if I'm correct that there is no
binary hidden somewhere in the packages.[ CC to hackers.]
Should we consider moving pg_filedump into our /contrib?
If it's license-compatible, +1.
It is GPL, which strictly speaking is compatible, but we don't want to
ship it to avoid problems for downstream packagers.
Could we ask Redhat for a relicense?
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Bruce Momjian <bruce@momjian.us> writes:
Should we consider moving pg_filedump into our /contrib?
Can't: it's GPL.
regards, tom lane
On Thu, Oct 14, 2010 at 05:53:30PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Should we consider moving pg_filedump into our /contrib?
Can't: it's GPL.
Depends on whether we can get it relicensed.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On Thu, Oct 14, 2010 at 2:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Bruce Momjian <bruce@momjian.us> writes:
Should we consider moving pg_filedump into our /contrib?
Can't: it's GPL.
I don't particularly see a problem with having GPL'd contrib modules.
It would mean any users hoping to redistribute the package couldn't
include those modules except under the GPL. But most repackagers don't
include the contrib modules anyways. Even ones that do and want to
include those modules would only have to include the source to that
module.
I can see not wanting to let that camel's nose in for fear of having
packagers always be uncertain about the status of each contrib module
though.
--
greg
On Fri, Oct 15, 2010 at 2:36 AM, Greg Stark <gsstark@mit.edu> wrote:
On Thu, Oct 14, 2010 at 2:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Bruce Momjian <bruce@momjian.us> writes:
Should we consider moving pg_filedump into our /contrib?
Can't: it's GPL.
I don't particularly see a problem with having GPL'd contrib modules.
It would mean any users hoping to redistribute the package couldn't
include those modules except under the GPL. But most repackagers don't
include the contrib modules anyways. Even ones that do and want to
include those modules would only have to include the source to that
module.I can see not wanting to let that camel's nose in for fear of having
packagers always be uncertain about the status of each contrib module
though.
I think that's a bad idea for all kinds of reasons. For one thing, it
seems that someone could easily end up copying some of that code into
some other place. It would be *nice* to have this available as part
of our regular distribution but I don't want to take any risk of GPL
contamination.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 10/15/2010 7:24 AM, Robert Haas wrote:
I think that's a bad idea for all kinds of reasons. For one thing, it
seems that someone could easily end up copying some of that code into
some other place. It would be *nice* to have this available as part
of our regular distribution but I don't want to take any risk of GPL
contamination.
I think there's a tendency to assume that one license rules them all
within a single package, tarball etc.
Just wondering what was the motivation to GPL this code ?
I mean, if I were to write a utility that was only useful for project X,
I'd want to license my code with the same (or a compatible) license
as X. I'd need a really good reason to use a different license.
On 10/15/2010 02:36 AM, Greg Stark wrote:
On Thu, Oct 14, 2010 at 2:53 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
Bruce Momjian<bruce@momjian.us> writes:
Should we consider moving pg_filedump into our /contrib?
Can't: it's GPL.
I don't particularly see a problem with having GPL'd contrib modules.
It would mean any users hoping to redistribute the package couldn't
include those modules except under the GPL. But most repackagers don't
include the contrib modules anyways. Even ones that do and want to
include those modules would only have to include the source to that
module.I can see not wanting to let that camel's nose in for fear of having
packagers always be uncertain about the status of each contrib module
though.
Didn't we go through the exercise of removing modules that were GPLed a
few years ago?
Having a plethora of different licenses covering code in our repository
seems like a recipe for major confusion, and I think is to be avoided.
cheers
andrew
Robert Haas <robertmhaas@gmail.com> writes:
On Fri, Oct 15, 2010 at 2:36 AM, Greg Stark <gsstark@mit.edu> wrote:
I don't particularly see a problem with having GPL'd contrib modules.
I think that's a bad idea for all kinds of reasons.
Yeah. From my viewpoint as a downstream packager, it creates a mess.
We've spent a great amount of effort and cajolery over the years to make
sure that the Postgres sources, including contrib, are uniformly
licensed. We're not going to abandon that policy.
I have no idea whether Red Hat could be persuaded to relicense
pg_filedump. It might be worth asking though.
regards, tom lane
David Boreham <david_list@boreham.org> writes:
Just wondering what was the motivation to GPL this code ?
It was written at Red Hat and they have (or at least had at the time)
a company policy of using GPL for any code written in-house.
regards, tom lane
Greg Stark wrote:
On Thu, Oct 14, 2010 at 2:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Bruce Momjian <bruce@momjian.us> writes:
Should we consider moving pg_filedump into our /contrib?
Can't: it's GPL.
I don't particularly see a problem with having GPL'd contrib modules.
It would mean any users hoping to redistribute the package couldn't
include those modules except under the GPL. But most repackagers don't
include the contrib modules anyways. Even ones that do and want to
include those modules would only have to include the source to that
module.I can see not wanting to let that camel's nose in for fear of having
packagers always be uncertain about the status of each contrib module
though.
I think we should just link to the tool from our docs so there is no
license complexity. Where do we add it?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +