Thread: New project launched : PostgreSQL GUI Installer for Linux/Unix systems
Hi, As you know, many databases that run on Linux / Unix systems have a GUI installer which make installation easier and more attractive for some people. Our Windows Installer is very attractive, for example. Now, I and Burcu Guzel, who is a Senior Programmer, decided to launch a new project: pgnixinstaller : http://pgfoundry.org/projects/pgnixinstaller/ We are actively looking for developers for the project. Please drop me an e-mail if you want to join this project. We will use Python, so you need to be a Python guy to join the project. We are in planning phase, if you join us earlier, we will be able to share more ideas. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Devrim GUNDUZ <devrim@commandprompt.com> writes: > http://pgfoundry.org/projects/pgnixinstaller/ > > We are actively looking for developers for the project. Please drop me > an e-mail if you want to join this project. We will use Python, so you > need to be a Python guy to join the project. We are in planning phase, > if you join us earlier, we will be able to share more ideas. What value does this bring to systems that have a good package system and up-to-date repositories? I can install Postgres today on Ubuntu using a GUI tool, and install another GUI tool to configure and adminsiter it. For systems like Solaris I can see it maybe being a win. Are you going to work with the underlying system's package manager, or put everything in /usr/local? -Doug
Hi, On Mon, 2006-01-30 at 20:03 -0500, Doug McNaught wrote: > > We are actively looking for developers for the project. Please drop me > > an e-mail if you want to join this project. We will use Python, so you > > need to be a Python guy to join the project. We are in planning phase, > > if you join us earlier, we will be able to share more ideas. > > What value does this bring to systems that have a good package system > and up-to-date repositories? I can install Postgres today on Ubuntu > using a GUI tool, and install another GUI tool to configure and > adminsiter it. You can install, but what if you need different configure options than the package provides? This means a rebuild of the package. Instead, we will build and install that package via the installer. OTOH, exluding Synaptic that I hate to use, FC / RH does not have a GUI RPM interface for the repositories. So our installer will help them a lot. Also, our installer will have an option to download and install the prebuilt binaries from PostgreSQL FTP site (and possible other sites) > For systems like Solaris I can see it maybe being a win. Agreed. > Are you going to work with the underlying system's package manager, or > put everything in /usr/local? We'll work with the package manager -- I'm an RPM guy ;) Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Devrim GUNDUZ wrote: >OTOH, exluding Synaptic that I hate to use, FC / RH does not have a GUI >RPM interface for the repositories. So our installer will help them a >lot. Also, our installer will have an option to download and install the >prebuilt binaries from PostgreSQL FTP site (and possible other sites) > > > There's yumex ... http://fedoranews.org/tchung/yumex/ cheers andrew
Devrim GUNDUZ <devrim@commandprompt.com> writes: > On Mon, 2006-01-30 at 20:03 -0500, Doug McNaught wrote: > >> What value does this bring to systems that have a good package system >> and up-to-date repositories? I can install Postgres today on Ubuntu >> using a GUI tool, and install another GUI tool to configure and >> adminsiter it. > > You can install, but what if you need different configure options than > the package provides? This means a rebuild of the package. Instead, we > will build and install that package via the installer. That's actually a pretty cool idea--compile and generate debs/rpms that reflect the user's choices, then install them. But the dependency on a compiler adds a twist of complexity--"sorry, you need to install the following system packages (gcc, etc) before you can install Postgres as you've configured it." Not horrible, but perhaps intimidating for the GUI crowd? :) Is gcc in the bog-standard default install on FC these days? Certainly you can install pre-built binaries without a compiler, and let the user choose database location, autovacuum settings and stuff like that. Good luck! -Doug
Hi, On Mon, 2006-01-30 at 20:27 -0500, Andrew Dunstan wrote: > >OTOH, exluding Synaptic that I hate to use, FC / RH does not have a GUI > >RPM interface for the repositories. So our installer will help them a > >lot. Also, our installer will have an option to download and install the > >prebuilt binaries from PostgreSQL FTP site (and possible other sites) > > There's yumex ... http://fedoranews.org/tchung/yumex/ Thanks for the info. I haven't heard about it before... However none of them are PostgreSQL Installers, none of them has the ability to customize the packages and none of them has the ability to install the community packages, etc. :) Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Tue, 31 Jan 2006, Devrim GUNDUZ wrote: > Hi, > > On Mon, 2006-01-30 at 20:03 -0500, Doug McNaught wrote: > >>> We are actively looking for developers for the project. Please drop me >>> an e-mail if you want to join this project. We will use Python, so you >>> need to be a Python guy to join the project. We are in planning phase, >>> if you join us earlier, we will be able to share more ideas. >> >> What value does this bring to systems that have a good package system >> and up-to-date repositories? I can install Postgres today on Ubuntu >> using a GUI tool, and install another GUI tool to configure and >> adminsiter it. > > You can install, but what if you need different configure options than > the package provides? This means a rebuild of the package. Instead, we > will build and install that package via the installer. > > OTOH, exluding Synaptic that I hate to use, FC / RH does not have a GUI > RPM interface for the repositories. So our installer will help them a > lot. Also, our installer will have an option to download and install the > prebuilt binaries from PostgreSQL FTP site (and possible other sites) And pull down/build/install the various extensions on pgFoundry? :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Hi, On Mon, 2006-01-30 at 20:31 -0500, Doug McNaught wrote: > > Certainly you can install pre-built binaries without a compiler, and > let the user choose database location, autovacuum settings and stuff > like that. That's another good point. We can adjust many settings before installing. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Hi, On Mon, 2006-01-30 at 21:34 -0400, Marc G. Fournier wrote: > > OTOH, exluding Synaptic that I hate to use, FC / RH does not have a GUI > > RPM interface for the repositories. So our installer will help them a > > lot. Also, our installer will have an option to download and install the > > prebuilt binaries from PostgreSQL FTP site (and possible other sites) > > And pull down/build/install the various extensions on pgFoundry? :) Another good idea. Thanks Marc. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Hi, On Mon, 2006-01-30 at 20:31 -0500, Doug McNaught wrote: > > You can install, but what if you need different configure options than > > the package provides? This means a rebuild of the package. Instead, we > > will build and install that package via the installer. > > That's actually a pretty cool idea--compile and generate debs/rpms > that reflect the user's choices, then install them. But the > dependency on a compiler adds a twist of complexity--"sorry, you need > to install the following system packages (gcc, etc) before you can > install Postgres as you've configured it." Not horrible, but perhaps > intimidating for the GUI crowd? :) Is gcc in the bog-standard > default install on FC these days? We can pre-check the prerequisites for building the package and raise an error before beginning to build the package. It is not that hard. For example, RPMs have BuildRequires tags and we can compare those with the packages installed in the system. BTW, gcc is not installed on by default AFAIR. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Tue, 31 Jan 2006, Devrim GUNDUZ wrote: > BTW, gcc is not installed on by default AFAIR. Wow, how do you update the kernel each week? :) More seriously, I know under FreeBSD, one of the first things that gets done after installing is to customize the kernel to get rid of all the 'cruft' part of the generic kernel, I take it that this isn't something that ppl do with Linux? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Hi, On Mon, 2006-01-30 at 22:04 -0400, Marc G. Fournier wrote: >> BTW, gcc is not installed on by default AFAIR. > > Wow, how do you update the kernel each week? :) > > More seriously, I know under FreeBSD, one of the first things that gets > done after installing is to customize the kernel to get rid of all the > 'cruft' part of the generic kernel, I take it that this isn't something > that ppl do with Linux? On systems that have a packaging system, you are supposed to download and install vendor kernels. There is "no need" to build the kernel. However, if you want to build, then you need to install development environment. On my RHEL boxes, I do never ever recompile the kernel since Red Hat does not provide support if I do so :) Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Tue, 31 Jan 2006, Devrim GUNDUZ wrote: > On my RHEL boxes, I do never ever recompile the kernel since Red Hat > does not provide support if I do so :) Is everything 'loadable modules' then? I can't imagine you have some mammoth kernel running on your system, do you? with every conceivable piece of hardware configured in? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > > More seriously, I know under FreeBSD, one of the first things that > gets done after installing is to customize the kernel to get rid of > all the 'cruft' part of the generic kernel, I take it that this isn't > something that ppl do with Linux? > The Linux kernel has loadable modules, so it's much less of an issue. For example, I just installed the Cisco VPN s/w on my FC4 box. I didn't have to rebuild the kernel, all I have to do is to load the kernel module that puts a wedge in the IP stack. The parts of the kernel that are optional are almost all loadable modules. Some people do build static kernels. That makes sense when you have tightly controlled hardware and software requirements. I mostly don't bother. cheers andrew
I had to deal with an installer written in python and several in Java... IMHO, Java would be a better language for this and you could build off some nice OSS installers that already exist (such as IzPack). Just my 2 cents :)
On 1/30/06, Devrim GUNDUZ <devrim@commandprompt.com> wrote:
Hi,
On Mon, 2006-01-30 at 22:04 -0400, Marc G. Fournier wrote:
>> BTW, gcc is not installed on by default AFAIR.
>
> Wow, how do you update the kernel each week? :)
>
> More seriously, I know under FreeBSD, one of the first things that gets
> done after installing is to customize the kernel to get rid of all the
> 'cruft' part of the generic kernel, I take it that this isn't something
> that ppl do with Linux?
On systems that have a packaging system, you are supposed to download
and install vendor kernels. There is "no need" to build the kernel.
However, if you want to build, then you need to install development
environment.
On my RHEL boxes, I do never ever recompile the kernel since Red Hat
does not provide support if I do so :)
Regards,
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
"Marc G. Fournier" <scrappy@postgresql.org> writes: > On Tue, 31 Jan 2006, Devrim GUNDUZ wrote: > >> On my RHEL boxes, I do never ever recompile the kernel since Red Hat >> does not provide support if I do so :) > > Is everything 'loadable modules' then? I can't imagine you have some > mammoth kernel running on your system, do you? with every conceivable > piece of hardware configured in? Yes, vendor kernels are very modular--most drivers, packet filtering, scsi etc are all loadable modules. You can of course build your own kernel with only the drivers you need built-in, but it usually doesn't make very much difference. The module system works, in general, extremely well. -Doug
Re: New project launched : PostgreSQL GUI Installer for Linux/Unix systems
From
Christopher Browne
Date:
> We are actively looking for developers for the project. Please drop me > an e-mail if you want to join this project. We will use Python, so you > need to be a Python guy to join the project. We are in planning phase, > if you join us earlier, we will be able to share more ideas. You'd better define the purpose pretty clearly, as I don't see any purpose that's of value, yet. On my Debian systems, I can install PostgreSQL quite readily via the command "apt-get install postgresql-8.1", which can get GUIed at least somewhat if I run aptitude, synaptic, or such... I could see there being some value in a GUI for managing postmaster config files... -- let name="cbbrowne" and tld="gmail.com" in String.concat "@" [name;tld];; http://cbbrowne.com/info/linuxdistributions.html "High-level languages are a pretty good indicator that all else is seldom equal." - Tim Bradshaw, comp.lang.lisp
On Jan 30, 2006, at 8:32 PM, Devrim GUNDUZ wrote: > However none of them are PostgreSQL Installers, none of them has the > ability to customize the packages and none of them has the ability to > install the community packages, etc. :) You need to take a sniff over at the FreeBSD ports. Lets you build customized install of Pg quite easily, without need for a gui, which none of my big servers have.
Marc G. Fournier wrote: > On Tue, 31 Jan 2006, Devrim GUNDUZ wrote: > >> On my RHEL boxes, I do never ever recompile the kernel since Red Hat >> does not provide support if I do so :) > > > Is everything 'loadable modules' then? I can't imagine you have some > mammoth kernel running on your system, do you? with every conceivable > piece of hardware configured in? Yes except for "core" modules almost everything in Linux is a loadable module. Sincerely, Joshua D. Drake
> > >On my Debian systems, I can install PostgreSQL quite readily via the >command "apt-get install postgresql-8.1", which can get GUIed at least >somewhat if I run aptitude, synaptic, or such... > > Yes Christopher, you can... I can, and Devrim can.... As more and more people come on board people are going to want to download a .exe (a metaphor), double click and have it open an installer, they will then want to click next, next, continue, finish. You don't get that with apt-get install. There is a reason that even Oracle has a graphical installer on Linux, because most people installing the software: A. Don't know how to use it B. Probably don't know how to use Linux C. Don't want to. Joshua D. Drake
On Mon, 30 Jan 2006, Joshua D. Drake wrote: >> >> >> On my Debian systems, I can install PostgreSQL quite readily via the >> command "apt-get install postgresql-8.1", which can get GUIed at least >> somewhat if I run aptitude, synaptic, or such... >> > Yes Christopher, you can... I can, and Devrim can.... > > As more and more people come on board people are going to want to download a > .exe (a metaphor), > double click and have it open an installer, they will then want to click > next, next, continue, finish. > > You don't get that with apt-get install. > > There is a reason that even Oracle has a graphical installer on Linux, > because most people installing > the software: > > A. Don't know how to use it > B. Probably don't know how to use Linux > C. Don't want to. i can't agree more ... I don't care whether you are running FreeBSD or Linux or Solaris ... if you want broader adoption of non-Microsoft OSs, you have to make it simplier for 'the masses' to make use of ... and GUIs tend to follow KISS very closely ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
I don't see why anyone has a problem with this. I am certainly never going to use it but if it helps someone who isn't a linux person to use it on a project when they would have used something else (like mysql) or if it convinces someone to run postgres on linux instead of windows because they now have a graphical installer on linux then it seems like a good thing to me. More users = bigger community = larger potential pool of people to help out. Even if people can't code they can answer newbie (or advanced) questions on the mailing lists or write documentation or even just tell their dba friends about it. The more people using postgres the better. If this will help then I'm all for it. Just because I would rather do a ./configure make make install doesn't mean that thats the best route for everyone. Rick On Jan 30, 2006, at 8:58 PM, Marc G. Fournier wrote: > On Mon, 30 Jan 2006, Joshua D. Drake wrote: > >>> On my Debian systems, I can install PostgreSQL quite readily via the >>> command "apt-get install postgresql-8.1", which can get GUIed at >>> least >>> somewhat if I run aptitude, synaptic, or such... >> Yes Christopher, you can... I can, and Devrim can.... >> >> As more and more people come on board people are going to want to >> download a .exe (a metaphor), >> double click and have it open an installer, they will then want to >> click next, next, continue, finish. >> >> You don't get that with apt-get install. >> >> There is a reason that even Oracle has a graphical installer on >> Linux, because most people installing >> the software: >> >> A. Don't know how to use it >> B. Probably don't know how to use Linux >> C. Don't want to. > > i can't agree more ... I don't care whether you are running FreeBSD > or Linux or Solaris ... if you want broader adoption of non- > Microsoft OSs, you have to make it simplier for 'the masses' to > make use of ... and GUIs tend to follow KISS very closely ... > > ---- > Marc G. Fournier Hub.Org Networking Services (http:// > www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: > 7615664 > > ---------------------------(end of > broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster >
On Mon, 2006-01-30 at 19:52 -0800, Joshua D. Drake wrote: > > > > > >On my Debian systems, I can install PostgreSQL quite readily via the > >command "apt-get install postgresql-8.1", which can get GUIed at least > >somewhat if I run aptitude, synaptic, or such... > > > > > Yes Christopher, you can... I can, and Devrim can.... > > As more and more people come on board people are going to want to > download a .exe (a metaphor), > double click and have it open an installer, they will then want to click > next, next, continue, finish. There is such a thing as best practices. If you install postgresql in this glorious graphical manner, what will prevent you from accidentally upgrading a shared library which postgresql depends upon? Nothing, really, unless this installer is going to be able to customize, build, and install a native package on all the target operating systems. How will you do an orderly upgrade from one revision to the next, including all the dependencies? How will you distribute security updates? I predict this form of installation will cause a great many support headaches as users report problems which are caused by oddball compilers, strange CFLAGS, unreleased or strangely patched versions of shared libraries and headers, and so forth. > You don't get that with apt-get install. Right, with apt-get install you get a package built with a known-good compiler, known-sane configure flags, and a method of pinning the dependencies, which passes at the very least a smoketest on Alpha, AMD64, ARM, HPPA, x86, IA64, 640x0, MIPS, PowerPC, S/390, and SPARC. > There is a reason that even Oracle has a graphical installer on Linux, > because most people installing > the software: > > A. Don't know how to use it > B. Probably don't know how to use Linux > C. Don't want to. Oracle's graphical installer is a material impediment to Oracle adoption. The installer only works on systems where particular versions of Java and Motif libraries are available. On 64-bit Opteron systems it only works with the peculiar 32-bit thunking tree favored by Red Hat and hardly anybody else. If I could install Oracle on Debian/AMD64 with a shell script, I'd drop Postgresql in a heartbeat. Obviously anybody is welcome and able to just write whatever software they feel is needed, but go ahead and count me among the skeptics. -jwb
Devrim GUNDUZ wrote: Have you looked at AutoPackage? http://autopackage.org screen shots. http://autopackage.org/gallery.html Has a GUI wizard if X windows is available and a command line wizard if no X is available. Using autopackage is similar to using MSI,Wise,Inno etc on Windows. Later, -- Tony Caduto AM Software Design Home of PG Lightning Admin for Postgresql http://www.amsoftwaredesign.com
> Oracle's graphical installer is a material impediment to Oracle > adoption. The installer only works on systems where particular versions > of Java and Motif libraries are available. On 64-bit Opteron systems it > only works with the peculiar 32-bit thunking tree favored by Red Hat and > hardly anybody else. > > If I could install Oracle on Debian/AMD64 with a shell script, I'd drop > Postgresql in a heartbeat. > > Obviously anybody is welcome and able to just write whatever software > they feel is needed, but go ahead and count me among the skeptics. > The installer is for the 98% not the 2%. You are in the 2%. Joshua D. Drake > -jwb > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
On Mon, 2006-01-30 at 20:53 -0800, Joshua D. Drake wrote: > > Oracle's graphical installer is a material impediment to Oracle > > adoption. The installer only works on systems where particular versions > > of Java and Motif libraries are available. On 64-bit Opteron systems it > > only works with the peculiar 32-bit thunking tree favored by Red Hat and > > hardly anybody else. > > > > If I could install Oracle on Debian/AMD64 with a shell script, I'd drop > > Postgresql in a heartbeat. > > > > Obviously anybody is welcome and able to just write whatever software > > they feel is needed, but go ahead and count me among the skeptics. > > > The installer is for the 98% not the 2%. You are in the 2%. Right, and it would make FAR more sense if Oracle just shipped the whole thing, operating system and the works, on a single installer image. So why don't you just do that with Postgres? You could call it "Bootable PostgreSQL". It would be a big hit. When a new version comes out, you can just mail out a new DVD. That would be a lot better than pretending to know how to fit in, best practices and the works, with all the various Unix systems out there. -jwb
Jeff, > So why don't you just do that with Postgres? You could call it > "Bootable PostgreSQL". It would be a big hit. When a new version comes > out, you can just mail out a new DVD. Actually, we have these. We give them out at conferences. --Josh
On Jan 30, 2006, at 8:48 PM, Tony Caduto wrote: > Devrim GUNDUZ wrote: > > Have you looked at AutoPackage? > > http://autopackage.org > > screen shots. > > http://autopackage.org/gallery.html > > Has a GUI wizard if X windows is available and a command line > wizard if no X is available. > > > Using autopackage is similar to using MSI,Wise,Inno etc on Windows. If that's the one that uses aptools it looks _excellent_. Until you try and use it. It looked as though it would solve many of my packaging problems, not least deploying on older platforms than the build box, but simply didn't work on anything more complex than toy code. I suspect that if you were just using it as a general installer, rather than any of the portability magic, it might be worth a look. Cheers, Steve
Devrim GUNDUZ schrieb: > Hi, > > As you know, many databases that run on Linux / Unix systems have a GUI > installer which make installation easier and more attractive for some > people. If you think of the *racle-GUI-Installer, most people find it very s*cking ;) > Our Windows Installer is very attractive, for example. > > Now, I and Burcu Guzel, who is a Senior Programmer, decided to launch a > new project: pgnixinstaller : > > http://pgfoundry.org/projects/pgnixinstaller/ > > We are actively looking for developers for the project. Please drop me > an e-mail if you want to join this project. We will use Python, so you > need to be a Python guy to join the project. We are in planning phase, > if you join us earlier, we will be able to share more ideas. Might be fun of course. But on unix you usually have some kind of package system anyway - how is the installer supposed to play nicely with them? Regards Tino
Devrim GUNDUZ schrieb: > Hi, > ... >>Are you going to work with the underlying system's package manager, or >>put everything in /usr/local? > > > We'll work with the package manager -- I'm an RPM guy ;) > RPM isnt the only packaging system out there ;)
Jonah H. Harris schrieb: > I had to deal with an installer written in python and several in Java... > IMHO, Java would be a better language for this and you could build off > some nice OSS installers that already exist (such as IzPack). Just my 2 > cents :) Yes! Use Java for ultimate suckiness of the installer ;) I love to install all X11, Java and stuff on a server to be able to install a package with about 1/10 the size ;) SCNR Tino
Joshua D. Drake schrieb: ... > As more and more people come on board people are going to want to > download a .exe (a metaphor), > double click and have it open an installer, they will then want to click > next, next, continue, finish. > > You don't get that with apt-get install. Well you can use a frontend and search and click as well. I see no problem - and it really works, as opposed to: > There is a reason that even Oracle has a graphical installer on Linux, > because most people installing > the software: > > A. Don't know how to use it > B. Probably don't know how to use Linux > C. Don't want to. Hehehe. Did you actually use this installer? I did! And lets tell you, you dont come by w/o any linux/unix knowledge. Regards Tino
On Tue, 31 Jan 2006, Tino Wildenhain wrote: > Devrim GUNDUZ schrieb: >> Hi, >> > ... >>> Are you going to work with the underlying system's package manager, or >>> put everything in /usr/local? >> >> >> We'll work with the package manager -- I'm an RPM guy ;) >> > RPM isnt the only packaging system out there ;) I thought that Linux had this 'Linux Standard File System' or some such that described where files were supposed to be installed? Or is this another one of those Standards that nobody follows? :( I know under FreeBSD, its simple: --prefix=/usr/local and away you go ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Rick Gigger schrieb: > I don't see why anyone has a problem with this. I am certainly never > going to use it but if it helps someone who isn't a linux person to use > it on a project when they would have used something else (like mysql) > or if it convinces someone to run postgres on linux instead of windows > because they now have a graphical installer on linux then it seems like > a good thing to me. More users = bigger community = larger potential > pool of people to help out. Even if people can't code they can answer > newbie (or advanced) questions on the mailing lists or write > documentation or even just tell their dba friends about it. > > The more people using postgres the better. If this will help then I'm > all for it. Just because I would rather do a ./configure make make > install doesn't mean that thats the best route for everyone. As was said, a gui to produce postgresql.conf files (off host) can be of value. Also for the tune-people a package builder can be useful too. For other people - if they dont learn a bit about their package system on their choosen system - they will run into other problems soon or later.
On Jan 30, 2006, at 7:52 PM, Joshua D. Drake wrote: > There is a reason that even Oracle has a graphical installer on > Linux, because most people installing > the software: > > A. Don't know how to use it > B. Probably don't know how to use Linux > C. Don't want to. Except that the Oracle "graphical installer" usually requires a non- trivial amount of command line kung-fu that alone is more complex than the entirety of the command line installation of PostgreSQL. Oracle installation is an unpleasant and painful process even under the best of circumstances, and I've never had one that required less effort than Postgres for a vanilla install. And I always install postgres from source. If "./configure; make; make install" scares away people, sorting out the dependency hell getting the Oracle installer to even run on nominally supported platforms will definitely scare them away. A graphical installer for Unix is fine, but please, do not make it anything like Oracle's graphical installer. Oracle's graphical install process gives command line installs a good name for ease of use. J. Andrew Rogers
On Tue, 2006-01-31 at 03:50 -0400, Marc G. Fournier wrote: > On Tue, 31 Jan 2006, Tino Wildenhain wrote: > > > Devrim GUNDUZ schrieb: > >> Hi, > >> > > ... > >>> Are you going to work with the underlying system's package manager, or > >>> put everything in /usr/local? > >> > >> > >> We'll work with the package manager -- I'm an RPM guy ;) > >> > > RPM isnt the only packaging system out there ;) > > I thought that Linux had this 'Linux Standard File System' or some such > that described where files were supposed to be installed? Or is this > another one of those Standards that nobody follows? :( Package management goes beyond sticking the files in the right place. If that were the only requirement, then tar(1) would be a package manager. As for the Linux Standards Base, that is little more than Red Hat and their like-minded friends getting together in a committee and declaring the way they already do everything to be a "standard". Generally the LSB holds the short-term needs of commercial Linux distributors above other considerations. -jwb
Tino Wildenhain wrote: > Jonah H. Harris schrieb: >> I had to deal with an installer written in python and several in >> Java... IMHO, Java would be a better language for this and you could >> build off some nice OSS installers that already exist (such as >> IzPack). Just my 2 cents :) > > Yes! Use Java for ultimate suckiness of the installer ;) I love to > install all X11, Java and stuff on a server to be able to install > a package with about 1/10 the size ;) > How about postponing choice of implementation language until it's clear what it is that should be implemented ;-) Regards, Thomas Hallgren
Hi, On Tue, 2006-01-31 at 08:34 +0100, Tino Wildenhain wrote: > > http://pgfoundry.org/projects/pgnixinstaller/ > > > > We are actively looking for developers for the project. Please drop me > > an e-mail if you want to join this project. We will use Python, so you > > need to be a Python guy to join the project. We are in planning phase, > > if you join us earlier, we will be able to share more ideas. > > Might be fun of course. But on unix you usually have some kind > of package system anyway - how is the installer supposed to > play nicely with them? Yes, We will try to stick the file locations of those package managers. We already have that KB. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Hi, On Tue, 2006-01-31 at 08:36 +0100, Tino Wildenhain wrote: > >>Are you going to work with the underlying system's package manager, or > >>put everything in /usr/local? > > > > > > We'll work with the package manager -- I'm an RPM guy ;) > > > RPM isnt the only packaging system out there ;) I used RPM as an alias to package managers :) Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Hi, On Mon, 2006-01-30 at 20:41 -0800, Jeffrey W. Baker wrote: > How will you do an orderly upgrade from one revision to the next, > including all the dependencies? We are still in planning phase, any ideas of how to do that is welcome. > How will you distribute security updates? We are still in planning phase, any ideas of how to do that is welcome. > I predict this form of installation will cause a great many support > headaches as users report problems which are caused by oddball > compilers, strange CFLAGS, unreleased or strangely patched versions of > shared libraries and headers, and so forth. I can't see a problem in here. We already have platform test results in pgbuildfarm and we have the knowledbase about the configure options, flags etc. in that platforms. > Obviously anybody is welcome and able to just write whatever software > they feel is needed, but go ahead and count me among the skeptics. The world is not turning around us, and please don't be skeptic on a piece of software that you won't use but some people will. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Hi, On Mon, 2006-01-30 at 22:45 -0500, Vivek Khera wrote: > > However none of them are PostgreSQL Installers, none of them has the > > ability to customize the packages and none of them has the ability to > > install the community packages, etc. :) > > You need to take a sniff over at the FreeBSD ports. Lets you build > customized install of Pg quite easily, without need for a gui, which > none of my big servers have. There are some people who do use GUI on their servers and do not know how to compile a software or do not want to build a software via command line. This is called "marketing". :) Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Hi, On Mon, 2006-01-30 at 19:35 -0800, Christopher Browne wrote: > > We are actively looking for developers for the project. Please drop me > > an e-mail if you want to join this project. We will use Python, so you > > need to be a Python guy to join the project. We are in planning phase, > > if you join us earlier, we will be able to share more ideas. > > You'd better define the purpose pretty clearly, as I don't see any > purpose that's of value, yet. I agree with Joshua's points here. Think of people who do not want an installation via command line. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Hi, On Mon, 2006-01-30 at 21:27 -0500, Jonah H. Harris wrote: > I had to deal with an installer written in python and several in > Java... IMHO, Java would be a better language for this and you could > build off some nice OSS installers that already exist (such as > IzPack). Just my 2 cents :) Bundling Java is a pain, so we'd better stay away from that. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Devrim GUNDUZ wrote: > Hi, > > On Mon, 2006-01-30 at 21:27 -0500, Jonah H. Harris wrote: >> I had to deal with an installer written in python and several in >> Java... IMHO, Java would be a better language for this and you could >> build off some nice OSS installers that already exist (such as >> IzPack). Just my 2 cents :) > > Bundling Java is a pain, so we'd better stay away from that. > There's always gcj. It's pretty mature by now. I'm not sure about availability compared to Python though, but I find it hard to believe it would be more painful. Regards, Thomas Hallgren
> Devrim GUNDUZ wrote: >> Hi, >> On Mon, 2006-01-30 at 21:27 -0500, Jonah H. Harris wrote: >>> I had to deal with an installer written in python and several in >>> Java... IMHO, Java would be a better language for this and you could >>> build off some nice OSS installers that already exist (such as >>> IzPack). Just my 2 cents :) >> Bundling Java is a pain, so we'd better stay away from that. >> > > There's always gcj. It's pretty mature by now. I'm not sure about > availability compared to Python though, but I find it hard to believe > it would be more painful. On several occasions, I have installed graphical Python apps; it has never been the bag of worms involved in getting a Java environment into place... -- select 'cbbrowne' || '@' || 'gmail.com'; http://linuxfinances.info/info/wp.html Signs of a Klingon Programmer #7: "Klingon function calls do not have 'parameters' -- they have 'arguments' -- and they ALWAYS WIN THEM."
> Hi, > > On Mon, 2006-01-30 at 22:45 -0500, Vivek Khera wrote: >> > However none of them are PostgreSQL Installers, none of them has the >> > ability to customize the packages and none of them has the ability to >> > install the community packages, etc. :) >> >> You need to take a sniff over at the FreeBSD ports. Lets you build >> customized install of Pg quite easily, without need for a gui, which >> none of my big servers have. > > There are some people who do use GUI on their servers and do not know > how to compile a software or do not want to build a software via command > line. > > This is called "marketing". :) I have to wonder if these people, so helpless that they cannot manage their Unix servers without this GUI tool, will be able to get any of the applications installed that were supposed to use the database. From what I can see, this is merely putting off the "learning cliff," and possibly in a dangerous way. -- let name="cbbrowne" and tld="gmail.com" in name ^ "@" ^ tld;; http://linuxfinances.info/info/nonrdbms.html Actually, typing random strings in the Finder does the equivalent of filename completion. (Discussion in comp.os.linux.misc on the intuitiveness of commands: file completion vs. the Mac Finder.)
> Hi, > > On Mon, 2006-01-30 at 19:35 -0800, Christopher Browne wrote: >> > We are actively looking for developers for the project. Please >> > drop me an e-mail if you want to join this project. We will use >> > Python, so you need to be a Python guy to join the project. We >> > are in planning phase, if you join us earlier, we will be able to >> > share more ideas. >> >> You'd better define the purpose pretty clearly, as I don't see any >> purpose that's of value, yet. > > I agree with Joshua's points here. Think of people who do not want > an installation via command line. When virtually every flavour of Unix has its own package manager, I have difficulty distinguishing this from the "badness" of how Oracle's installer handles things. The people I imagine would be of interest as plausible new users are the ones that don't want to be troubled with configuring pretty well anything at all, command line or no. The sort of thing that would get PostgreSQL much more widely deployed would be (for instance) for applications like GnuCash or components of GNOME/KDE to adopt it as their storage mechanism. Their developers are not particularly interested in doing a lot of DBA work, e.g. - setting up users, pg_hba.conf, and such. (The need for this is one of the reasons the GnuCash people have been biasing towards SQLite...) It's worth noting that GNOME/KDE projects have NOT attempted to build their own GUI installers except in the forms of very platform-specific things. In that regard, they let each platform have its own set of "idioms." -- let name="cbbrowne" and tld="gmail.com" in String.concat "@" [name;tld];; http://cbbrowne.com/info/slony.html CBS News report on Fort Worth tornado damage: "Eight major downtown buildings were severely damaged and 1,000 homes were damaged, with 95 uninhabitable. Gov. George W. Bush declared Tarrant County a disaster area. Federal Emergency Management Agency workers are expected to arrive sometime next week after required paperwork is completed."
Devrim GUNDUZ wrote: > Hi, > > On Mon, 2006-01-30 at 19:35 -0800, Christopher Browne wrote: >>> We are actively looking for developers for the project. Please drop me >>> an e-mail if you want to join this project. We will use Python, so you >>> need to be a Python guy to join the project. We are in planning phase, >>> if you join us earlier, we will be able to share more ideas. >> You'd better define the purpose pretty clearly, as I don't see any >> purpose that's of value, yet. > > I agree with Joshua's points here. Think of people who do not want an > installation via command line. Surely the only people installing from the command-line are those that want to. There's synaptic or yum or whatever to let you search for "postgresql" and handle all your dependencies for you. I mean *I* compile from source when I'm testing betas or want to backport and there's no package but I can't imagine most Ubuntu users bother. Now something to let you install extra modules, tune your postgresql.conf and pg_hba.conf - that's useful. If it can explain as it goes along, all the better (like "bastille linux"?) -- Richard Huxton Archonet Ltd
J. Andrew Rogers wrote: <snip> > A graphical installer for Unix is fine, but please, do not make it > anything like Oracle's graphical installer. Oracle's graphical install > process gives command line installs a good name for ease of use. > > > J. Andrew Rogers I heartily second that!
Christopher Browne wrote: >> Devrim GUNDUZ wrote: >>> Hi, >>> On Mon, 2006-01-30 at 21:27 -0500, Jonah H. Harris wrote: >>>> I had to deal with an installer written in python and several in >>>> Java... IMHO, Java would be a better language for this and you could >>>> build off some nice OSS installers that already exist (such as >>>> IzPack). Just my 2 cents :) >>> Bundling Java is a pain, so we'd better stay away from that. >>> >> There's always gcj. It's pretty mature by now. I'm not sure about >> availability compared to Python though, but I find it hard to believe >> it would be more painful. > > On several occasions, I have installed graphical Python apps; it has > never been the bag of worms involved in getting a Java environment > into place... Install gcj and you're up and running, graphics and all. What's the problem (besides your obvious aversion to Java)? Or take it one step further and use gcj to compile the Java code into statically linked binaries. Where's the pain, really? Regards, Thomas Hallgren
On Jan 31, 2006, at 12:54 AM, Tino Wildenhain wrote: > Rick Gigger schrieb: >> I don't see why anyone has a problem with this. I am certainly >> never going to use it but if it helps someone who isn't a linux >> person to use it on a project when they would have used something >> else (like mysql) or if it convinces someone to run postgres on >> linux instead of windows because they now have a graphical >> installer on linux then it seems like a good thing to me. More >> users = bigger community = larger potential pool of people to >> help out. Even if people can't code they can answer newbie (or >> advanced) questions on the mailing lists or write documentation >> or even just tell their dba friends about it. >> The more people using postgres the better. If this will help >> then I'm all for it. Just because I would rather do a ./ >> configure make make install doesn't mean that thats the best >> route for everyone. > > As was said, a gui to produce postgresql.conf files (off host) > can be of value. Also for the tune-people a package builder > can be useful too. > > For other people - if they dont learn a bit about their package system > on their choosen system - they will run into other problems soon or > later. Why would the necessarily have to run into problem with their packaging system. If someone installs from source it doesn't cause problems with packaging systems. Why should this have to be any different?
On Mon, Jan 30, 2006 at 08:53:54PM -0800, Joshua D. Drake wrote: > >If I could install Oracle on Debian/AMD64 with a shell script, I'd drop > >Postgresql in a heartbeat. > > > >Obviously anybody is welcome and able to just write whatever software > >they feel is needed, but go ahead and count me among the skeptics. > > > The installer is for the 98% not the 2%. You are in the 2%. I've yet to find *anyone* who likes the Oracle installer. It's absolutely the last thing I would use as a point of reference. Come to think of it, the DB2 installer was a pile of crap as well... My concern with this installer is that people are going to show up in -general or on IRC in droves with dependancy related problems with the installer. IMO it would be *much* better if we instead focused on something that made it easy to install stuff out of contrib and/or pgFoundry (and prefferably could be used without a GUI). But, OSS works by people scratching itches, so if there's folks who want to scratch this itch... -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Devrim GUNDUZ wrote: > Hi, > > As you know, many databases that run on Linux / Unix systems have a GUI > installer which make installation easier and more attractive for some > people. > > Our Windows Installer is very attractive, for example. > > Now, I and Burcu Guzel, who is a Senior Programmer, decided to launch a > new project: pgnixinstaller : > > http://pgfoundry.org/projects/pgnixinstaller/ > > We are actively looking for developers for the project. Please drop me > an e-mail if you want to join this project. We will use Python, so you > need to be a Python guy to join the project. We are in planning phase, > if you join us earlier, we will be able to share more ideas. > > Regards, Thanks to Devrim for the RPM stuff. On Windows, we expect the installer, no question about that. On Linux, virtually everyone including many beginners become familiar with their package management system, be it yum or apt etc. Many of the readme's, how-to's etc tie into it. The package management tools are packaged with every distro. There is no environment to setup. Whether you are using a headless box or a gnome desktop, there is usually an interface into them. The beginner just tries yum install xxx. I think folks would be surprised that for many folks this is basically IT for them in terms of package installation. Compiling from source, while theoretically sometimes as easy, doesn't happen nearly as often. And if you work with a client, the packaging system is what they know as well. Please, can't you set it up so everything comes from an RPM? I'm one of those people now. I used to compile everything from source, from apache, through php and my database. Had custom build scripts, and the whole works. But I threw it away and use RPM wherever I can. When I see postgresql packaged as an RPM, I'm pretty sure the file paths have been modified to work with my system (they are) and the startup and shutdown scripts tie in nicely (they do). Especially when I just want to play with something, I want the simplest approach possible. And the approach the most folks are familiar with is their package management system. So, what's the point of this rambling? Props to Devrim (and others) for hand-holding us beginners (or lazy ones) with his existing packaging work. It is tremendously appreciated and lowers the barrier to entry more then they release. And I wonder if an effort to take advantage of these existing infrastructures that everyone (including in my mind beginners) are familiar with, might yield good results. - For example, packaging the pgadmin adminpack as an rpm/deb and more of the pgfoundry items would do this. - Or a postgresql repository for apt/yum etc, making upgrading/installing even easier? If this new installer plays nice with existing packaging systems, and has the rules in place to custom compile lots of options, it seems close to providing something in this area already out of necessity. Perhaps a win-win for both areas with a bit of extension (ie, the installer is backed by a repo that other users can use with other tools?) - August