Thread: pgadmin3 debian package proposal
Hi guys, Michael Meskes (once again, thank you!) gave me a real good suggestion and I want to share this information with all of you as it can have many implications. One solution to be able to enter debian faster is to generate a debian package which would include our wx snapshot source and to build both the product together and do a static link of the wx part. I talked of this with my debian "sponsor" who thinks this is also the best way to handle this. I'm gonna work on this asap (in fact I already began to do it) and will inform you of the (non?)success of it. I may have to do some tricks to get the build running. In fact it's what is actually done in two shot that we have to handle in one :) I precise that the pgadmin3 binary package won't contain any part of wx but the ones linked statically to pgadmin3. One problem I can think of for now is that we will have to support bugs that may be due to our wx snapshot, and may be some really specifics one (architecture problems for example... Remember the crash problem on debian alpha). In fact nothing that we don't do for the moment isn't it ? As ever, any comments are welcome. Regards, Raphaël
Raphaël Enrici wrote: > Hi guys, > > Michael Meskes (once again, thank you!) gave me a real good suggestion > and I want to share this information with all of you as it can have > many implications. > One solution to be able to enter debian faster is to generate a debian > package which would include our wx snapshot source and to build both > the product together and do a static link of the wx part. I talked of > this with my debian "sponsor" who thinks this is also the best way to > handle this. > I'm gonna work on this asap (in fact I already began to do it) and > will inform you of the (non?)success of it. I may have to do some > tricks to get the build running. In fact it's what is actually done in > two shot that we have to handle in one :) I precise that the pgadmin3 > binary package won't contain any part of wx but the ones linked > statically to pgadmin3. > > One problem I can think of for now is that we will have to support > bugs that may be due to our wx snapshot, and may be some really > specifics one (architecture problems for example... Remember the crash > problem on debian alpha). In fact nothing that we don't do for the > moment isn't it ? > > As ever, any comments are welcome. Sounds good! So you're probably moving wx into the pgadmin3 directory, side by side to the now existing src, include and build? This would enable a common make run for all of pgadmin. This wouldn't only help for Debian, but for all other *nix makes also. I like that idea. People encountering any problem in pgAdmin3 will ask us for support anyway, and we'll have to trace it down to wx or even gtk, whether we're using an official wx distri or our own. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 25 October 2003 14:51 > To: Raphaël Enrici > Cc: pgadmin-hackers; Michael Meskes; Adam H. Pendleton > Subject: Re: [pgadmin-hackers] pgadmin3 debian package proposal > > Raphaël Enrici wrote: > > > One solution to be able to enter debian faster is to > generate a debian > > package which would include our wx snapshot source and to > build both > > the product together and do a static link of the wx part. Bizarre, I had exactly that thought on the way back from the shops earlier! > > Sounds good! > So you're probably moving wx into the pgadmin3 directory, > side by side to the now existing src, include and build? This > would enable a common make run for all of pgadmin. This > wouldn't only help for Debian, but for all other *nix makes > also. I like that idea. Side by side. Mmmm, if we're talking side by side right back to CVS, we really ought to be sure we want to do this. Basicallywe'd be committing to maintaining our own wx fork indefinately. Moving back to the standard distro might not beso easy in the future... That said, a single build system really would be nice. What are the licencing implications? > People encountering any problem in pgAdmin3 will ask us for > support anyway, and we'll have to trace it down to wx or even > gtk, whether we're using an official wx distri or our own. Very true. Regards, Dave.
> >Side by side. Mmmm, if we're talking side by side right back to CVS, we really ought to be sure we want to do this. Basicallywe'd be committing to maintaining our own wx fork indefinately. Moving back to the standard distro might not beso easy in the future... > > No, I don't want it put into cvs, except for some custom makefiles maybe. We should stay with the current way of syncing our snapshot with wx from time to time, hoping for an age where we can get back to vanilla wx. >That said, a single build system really would be nice. > If we have wx in a subdirectory of our source tree top side by side to src, the make process can do it in a single build. In this case, we wouldn't need to have wx installed, thus minimizing the chance of interference with an official wx package. Regards, Andreas
Andreas Pflug wrote: > >> >> Side by side. Mmmm, if we're talking side by side right back to CVS, >> we really ought to be sure we want to do this. Basically we'd be >> committing to maintaining our own wx fork indefinately. Moving back >> to the standard distro might not be so easy in the future... >> >> > No, I don't want it put into cvs, except for some custom makefiles > maybe. We should stay with the current way of syncing our snapshot > with wx from time to time, hoping for an age where we can get back to > vanilla wx. I agree with this. > > >> That said, a single build system really would be nice. > > If we have wx in a subdirectory of our source tree top side by side to > src, the make process can do it in a single build. In this case, we > wouldn't need to have wx installed, thus minimizing the chance of > interference with an official wx package. What I was imaginating was to find a proper way to put, for example, the .tar.bz2 of "our" wx source in a specific place and to have a "magic" configure (for example) option which could handle the fact that the wx to link against is situated in the source tree. I don't want to get the wx source always in pgadmin3 source tree, think it has nothing to do here and I don't want that we loose cpu time to build wx snap every day when building snapshots... By the way, it may not be a good idea to "waste" a lot of time to get the configure/makefiles modified to get a single build process. May be we could just try to have the proper way of launching each configure / make commands and to document it well so that all packagers can publish spec, rules or whatever is appropriate to each disto. It may than be easier to backout to a dynamic build against official wx when they will be ready. Another thing, may be we should not borrow Michael with these discuss anymore ? He had the good idea and may not want to receive all our thought about it (?) :) I'll send back to you my build process as soon as it will be ok (hope it will be ok one day) (depends on my free time). regards, Raphaël
Raphaël Enrici wrote: > Andreas Pflug wrote: > >> >> >>> That said, a single build system really would be nice. >> >> >> If we have wx in a subdirectory of our source tree top side by side >> to src, the make process can do it in a single build. In this case, >> we wouldn't need to have wx installed, thus minimizing the chance of >> interference with an official wx package. > just for information, I have a first debian package that build without external wx. I'm gonna submit it to my "sponsor" so that he can gives its advice and gave corrections. I'll send you some news asap. The method I adopted follows: pgadmin-1.1.0/wxWindows-pgAdmin3-20031010-5 contains the untared snapshot The debian/rules (equivalent of rpm spec file) is charged of building and installing it in pgadmin-1.1.0/wxWindows-pgAdmin3-20031010-5/localinst just before the pgA3 configure line is invoked.It refers to it using --with-wx and --with-wx-config configure options. regards, Raphaël