Thread: wxGTK2ud BuildRequires dependencies
Dear Devrim, Finally, I commented out the BuildRequires dependencies for wxGTK2ud in CVS. It appears that library names needed at build time are not the same under RedHat, Mandrake and SuSE. So, my 'stupid' recommended way is: rpmbuild --rebuild wxGTK2ud-2.5-xxxx.src.rpm 2>&1 | tee wxGTK2ud-2.5-xxxx.log and read the log to make sure all needed libraries display 'sys'. Do not hesitate to send me by email the wxGTK2ud (with 'sys' libraries) and pgAdmin3 (S)RPMs and I will publish them in a new Fedora section. Do not hesitate to sign your email with OpenPGP. By the way, would you be interested in releasing daily snapshots for Fedora? We always need help... Cheers, Jean-Michel -- Tel : +33(0)1 39 64 87 61 Mobile : +33 (0)6 76 88 60 29 Fax : +33(0)1 39 64 96 72 H323 phone : callto://translationforge.com ICQ 314352474 Mailto:jmpoure@translationforge.com 38 bld de la République 95160 MONTMORENCY France GNUPG Key fingerprint = AD25 3E5A 0AED B4BE 730F 6BE7 7B1B 681C 78F6 6053 GNUPG Key = http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x78F66053
Attachment
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear Jean-Michel,
On Sun, 16 Nov 2003, Jean-Michel POURE wrote:
> Do not hesitate to send me by email the wxGTK2ud (with 'sys' libraries) and
> pgAdmin3 (S)RPMs and I will publish them in a new Fedora section. Do not
> hesitate to sign your email with OpenPGP.
> By the way, would you be interested in releasing daily snapshots for Fedora?
> We always need help...
I can surely help. I've been "off" for 15 days. I "just" returned home and
trying to catch up what's happened :) I've build pgAdmin package of Fedora
on a computer that does not belong to me. I'll install FC 1 to my home and
office computers tomorrow(or tuesday) (I'm still running RH 9); so I can
begin building daily snapshots for FC after tomorrow.
So: I'll begin building tomorrow and send the URLs to you.
I'm glad that I found another chance to contribute the project, after
translation.
Regards,
- --
Devrim GUNDUZ
devrim@gunduz.org devrim.gunduz@linux.org.tr
http://www.tdmsoft.com
http://www.gunduz.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/t2T4tl86P3SPfQ4RAjmYAJ44biBAKqKDZNpJnxqICA0xT3MWUACdHhgv
aF2i3E2A3I/Q9r2QSUDUq8g=
=Dode
-----END PGP SIGNATURE-----
Le Dimanche 16 Novembre 2003 12:52, Devrim GUNDUZ a écrit : > So: I'll begin building tomorrow and send the URLs to you. > I'm glad that I found another chance to contribute the project, after > translation. Thanks. For sure, it is easier than sending an email. Cheers, J-Michel
Jean-Michel POURE wrote: >Dear Devrim, > >Finally, I commented out the BuildRequires dependencies for wxGTK2ud in CVS. > >It appears that library names needed at build time are not the same under >RedHat, Mandrake and SuSE. So, my 'stupid' recommended way is: > >rpmbuild --rebuild wxGTK2ud-2.5-xxxx.src.rpm 2>&1 | tee >wxGTK2ud-2.5-xxxx.log > > I realize it's a pain, but is it not possible to work the different sets of BuildRequires into the spec file, using distribution-dependent conditional statements? >and read the log to make sure all needed libraries display 'sys'. > >Do not hesitate to send me by email the wxGTK2ud (with 'sys' libraries) and >pgAdmin3 (S)RPMs and I will publish them in a new Fedora section. Do not >hesitate to sign your email with OpenPGP. > >By the way, would you be interested in releasing daily snapshots for Fedora? >We always need help... > > Incidentally, why are we building snapshots specifically for FC1? Is there a problem with the binary RPMs on Fedora? I have built the SRPMs with no trouble. ahp
Le Lundi 17 Novembre 2003 19:44, vous avez écrit : > I realize it's a pain, but is it not possible to work the different sets > of BuildRequires into the spec file, using distribution-dependent > conditional statements? Yes, it is perfectly possible. But, there are so many-many build-time depencies in wxWindows. Listing them all is quite difficult. On the other hand, the upcoming stable version of wxWindows 2.5.1 will provide a new set of RPMs. These "new" RPMs are very well designed. They include both buildtime and binary dependencies. Personaly, I think it is a waste of time to invest in the wxGTK2ud direction when a new set of RPMs is coming along. If you think the converse, do not hesitate to submit a patch and I will apply it immediately. This is free software... You are free to do what you want... Cheers, Jean-Michel
Jean-Michel POURE wrote:
BuildRequires: gtk2-devel, libjpeg-devel, libpng-devel, libtiff-devel
ahp
Really? Am I missing something, or would this line suffice (granted, this is the RH line, but...):Yes, it is perfectly possible. But, there are so many-many build-time depencies in wxWindows. Listing them all is quite difficult.
BuildRequires: gtk2-devel, libjpeg-devel, libpng-devel, libtiff-devel
So are we going to be using the official wxWindows RPMs from now on? Are we going to run into any problems since we currently use a build of wxWindows that differs from the "official" build?On the other hand, the upcoming stable version of wxWindows 2.5.1 will provide a new set of RPMs. These "new" RPMs are very well designed. They include both buildtime and binary dependencies. Personaly, I think it is a waste of time to invest in the wxGTK2ud direction when a new set of RPMs is coming along. If you think the converse, do not hesitate to submit a patch and I will apply it immediately. This is free software... You are free to do what you want...
ahp
Dear Adam, > Really? Am I missing something, or would this line suffice (granted, > this is the RH line, but...): > BuildRequires: gtk2-devel, libjpeg-devel, libpng-devel, libtiff-devel A lot more. A least, expat-devel, pango-devel, zlib-devel, X11-foo-devel, iconv-devel, etc... See the list below. Under SuSE and Mandrake, many of these libraries have different naming schemes. Since RPMs have automatic binary dependencies, looking at the SRPM rebuild log is enough for me ... All libraries should display "yes" or "sys". >So are we going to be using the official wxWindows RPMs from now on? >Are we going to run into any problems since we currently use a build of >wxWindows that differs from the "official" build? wxGTK-2.5.1 stable "official" release is not out yet. No idea when it will be released. The next official wx release has very designed RPM build scripts. I modified the scripts very slightly here: http://snake.pgadmin.org/jean-michel/makerpm.new Cheers, Jean-Michel *********** saving argument cache configarg.cache checking for toolkit... gtk checking for i686-pc-linux-gnu-gcc... no checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking whether gcc needs -traditional... no checking for i686-pc-linux-gnu-g++... no checking for i686-pc-linux-gnu-c++... no checking for i686-pc-linux-gnu-gpp... no checking for i686-pc-linux-gnu-aCC... no checking for i686-pc-linux-gnu-CC... no checking for i686-pc-linux-gnu-cxx... no checking for i686-pc-linux-gnu-cc++... no checking for i686-pc-linux-gnu-cl... no checking for i686-pc-linux-gnu-FCC... no checking for i686-pc-linux-gnu-KCC... no checking for i686-pc-linux-gnu-RCC... no checking for i686-pc-linux-gnu-xlC_r... no checking for i686-pc-linux-gnu-xlC... no checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for i686-pc-linux-gnu-ranlib... no checking for ranlib... ranlib checking for ar... ar checking for a BSD-compatible install... /usr/bin/install -c checking for strip... strip checking if make is GNU make... yes checking whether ln -s works... yes checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for strings.h... (cached) yes checking for stdlib.h... (cached) yes checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking for unistd.h... (cached) yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking fnmatch.h usability... yes checking fnmatch.h presence... yes checking for fnmatch.h... yes checking for fnmatch... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking X11/Xlib.h usability... yes checking X11/Xlib.h presence... yes checking for X11/Xlib.h... yes checking for X11/XKBlib.h... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for char... yes checking size of char... 1 checking for short... yes checking size of short... 2 checking for void *... yes checking size of void *... 4 checking for int... yes checking size of int... 4 checking for long... yes checking size of long... 4 checking for long long... yes checking size of long long... 8 checking size of wchar_t... 4 checking for _FILE_OFFSET_BITS value needed for large files... 64 checking if large file support is available... yes checking whether byte ordering is bigendian... no checking how to run the C++ preprocessor... g++ -E checking iostream usability... yes checking iostream presence... yes checking for iostream... yes checking if C++ compiler supports bool... yes checking if C++ compiler supports the explicit keyword... yes checking whether the compiler supports const_cast<>... yes checking for glibc 2.1 or later... yes checking regex.h usability... yes checking regex.h presence... yes checking for regex.h... yes checking for regcomp... yes checking for zlib.h >= 1.1.4... yes checking for zlib.h... (cached) yes checking for deflate in -lz... yes checking for png.h > 0.90... yes checking for png.h... (cached) yes checking for png_check_sig in -lpng... yes checking for jpeglib.h... yes checking for jpeg_read_header in -ljpeg... yes checking tiffio.h usability... yes checking tiffio.h presence... yes checking for tiffio.h... yes checking for TIFFError in -ltiff... yes checking expat.h usability... yes checking expat.h presence... yes checking for expat.h... yes checking if expat.h is valid C++ header... yes checking for XML_ParserCreate in -lexpat... yes checking mspack.h usability... no checking mspack.h presence... no checking for mspack.h... no checking for GTK+ version... checking for pkg-config... /usr/bin/pkg-config checking for GTK+ - version >= 2.0.0... yes (version 2.2.1) checking for pangoft2... yes checking PANGOFT2_CFLAGS... -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include checking PANGOFT2_LIBS... -Wl,--export-dynamic -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 checking for poll... yes checking for gdk_im_open in -lgdk... yes checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking for size_t... yes checking for uid_t in sys/types.h... yes checking if size_t is unsigned int... yes checking for pw_gecos in struct passwd... yes checking for wcslen... yes checking for wcsrtombs... yes checking for vsnprintf... yes checking for vsnprintf declaration... yes checking for fputwc... yes checking for wprintf... yes checking for vswprintf... yes checking for _vsnwprintf... no checking for iconv... yes checking if iconv needs const... no checking for sigaction... yes checking for sa_handler type... int checking for mkstemp... yes checking for statfs... yes checking for fcntl... yes checking for timegm... yes checking for putenv... yes checking for nanosleep... yes checking for uname... yes checking for strtok_r... yes checking for inet_addr... yes checking for inet_aton... yes checking for esd_close in -lesd... no checking for known CD-ROM interface... yes checking whether pthreads work with -pthread... yes checking if more special flags are required for pthreads... no checking for thr_setconcurrency... no checking sched.h usability... yes checking sched.h presence... yes checking for sched.h... yes checking for sched_yield... yes checking for pthread_attr_getschedpolicy... yes checking for pthread_attr_setschedparam... yes checking for sched_get_priority_max... yes checking for pthread_cancel... yes checking for pthread_mutexattr_t... yes checking for strptime... yes checking for timezone variable in <time.h>... timezone checking for localtime... yes checking for tm_gmtoff in struct tm... yes checking for gettimeofday... yes checking whether gettimeofday takes two arguments... yes checking for socket... yes checking what is the type of the third argument of getsockname... socklen_t checking linux/joystick.h usability... yes checking linux/joystick.h presence... yes checking for linux/joystick.h... yes checking for dlopen... no checking for dlopen in -ldl... yes checking for dlerror... no checking for dlerror in -ldl... yes checking for cos... no checking for floor... no checking if floating point functions link without -lm... no checking for sin... yes checking for ceil... yes checking if floating point functions link with -lm... yes
Jean-Michel POURE wrote:
[fmonkey@wrty Development]$ rpm -qR gtk2-devel
XFree86-devel
atk-devel >= 1.0.0-1
glib2-devel >= 2.2.0-1
gtk2 = 2.2.4
libc.so.6
libc.so.6(GLIBC_2.0)
libdl.so.2
libgdk_pixbuf-2.0.so.0
libglib-2.0.so.0
libgmodule-2.0.so.0
libgobject-2.0.so.0
libm.so.6
pango-devel >= 1.2.0-3
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
[fmonkey@wrty Development]$
In order to get gtk2-devel installed, these packages would also have to be installed. Also, any packages that those listed packages depend on would also have to be installed. Thus, by putting just gtk2-devel on the BuildRequires line, we implicity pull in the whole dependency tree for that package.
ahp
I may be wrong on this one, but I don't think there's any need to list these dependencies in the BuildRequire line. For example, by adding gtk2-devel, we implicity add these packages:A lot more. A least, expat-devel, pango-devel, zlib-devel, X11-foo-devel, iconv-devel, etc... See the list below. Under SuSE and Mandrake, many of these libraries have different naming schemes.
[fmonkey@wrty Development]$ rpm -qR gtk2-devel
XFree86-devel
atk-devel >= 1.0.0-1
glib2-devel >= 2.2.0-1
gtk2 = 2.2.4
libc.so.6
libc.so.6(GLIBC_2.0)
libdl.so.2
libgdk_pixbuf-2.0.so.0
libglib-2.0.so.0
libgmodule-2.0.so.0
libgobject-2.0.so.0
libm.so.6
pango-devel >= 1.2.0-3
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
[fmonkey@wrty Development]$
In order to get gtk2-devel installed, these packages would also have to be installed. Also, any packages that those listed packages depend on would also have to be installed. Thus, by putting just gtk2-devel on the BuildRequires line, we implicity pull in the whole dependency tree for that package.
What do you mean by automatic binary dependencies? I thought that RPM dependencies were enforced by the "Requires:" line in the spec file.Since RPMs have automatic binary dependencies, looking at the SRPM rebuild log is enough for me ... All libraries should display "yes" or "sys".
ahp
Hi Adam, Thanks for your explainations. The gtk-devel seems convincing. But there are other libraries. Feel free to submit a patch and I will integrate it immediately. > What do you mean by automatic binary dependencies? I thought that RPM > dependencies were enforced by the "Requires:" line in the spec file. If you do not write any "Requires:" line, RPM does it for you automatically. Cheers, Jean-Michel
Adam H. Pendleton wrote: >>So are we going to be using the official wxWindows RPMs from now on? >>Are we going to run into any problems since we currently use a build of >>wxWindows that differs from the "official" build? >> >> Still absolutely no, there's not a haze of work in committing my patches, not even commenting on it. If it makes sense, we'll snapshot whatever is agreed to work nicely for us, and then we'll add our own patches. Regards, Andreas
Adam H. Pendleton wrote: > Jean-Michel POURE wrote: > >>A lot more. A least, expat-devel, pango-devel, zlib-devel, X11-foo-devel, >>iconv-devel, etc... See the list below. Under SuSE and Mandrake, many of >>these libraries have different naming schemes. >> >> > I may be wrong on this one, but I don't think there's any need to list > these dependencies in the BuildRequire line. For example, by adding > gtk2-devel, we implicity add these packages: Hi Adam, Jean-Michel, I think Adam is right regarding dependencies, it's not usefull (and can get you to mistake if packages change) to specify all these dependencies. FYI Debian's dependencies I use are these (I cut debian specific things) Build-Depends: libgtk2.0-dev, gcc, g++, libjpeg62-dev, libpng-dev (>> 1.2.0) | libpng12-dev (>> 1.2.0) | libpng2-dev , libtiff3g-dev Isn't there a way to specify expressions like "or" (the '|' in debian) in rpms specs files ? That's what I used to solve the problem of package names changing from stable to testing and unstable. > What do you mean by automatic binary dependencies? I thought that RPM > dependencies were enforced by the "Requires:" line in the spec file. concerning this I find that RPM is too "agressive" while looking for dependencies. I'm not an RPM expert but when I do rpms packages I always do a first shot as is (without specifying anything) and I look to the result. Then I specify directly in the spec file not to look for dependencies and hard code them by hand. The "magic" flag is : AutoReqProv: no (http://linux.tnc.edu.tw/techdoc/maximum-rpm/rpmbook/node310.html). Regards, Raphaël
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 17 November 2003 23:23 > To: Adam H. Pendleton > Cc: jm@poure.com; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] wxGTK2ud BuildRequires dependencies > > Adam H. Pendleton wrote: > > >>So are we going to be using the official wxWindows RPMs > from now on? > >>Are we going to run into any problems since we currently > use a build > >>of wxWindows that differs from the "official" build? > >> > >> > Still absolutely no, there's not a haze of work in committing > my patches, not even commenting on it. Are you going to bother submitting more now they will probably reject them out of hand anyway? (For those that don't know, the wx team want all patch submitters to sign over copyright etc. on their code - this is at request of Borland). Regards, Dave.
Le Lundi 17 Novembre 2003 21:55, Raphaël Enrici a écrit : > I think Adam is right regarding dependencies, it's not usefull (and can > get you to mistake if packages change) to specify all these > dependencies. FYI Debian's dependencies I use are these (I cut debian > specific things) > > Build-Depends: libgtk2.0-dev, gcc, g++, libjpeg62-dev, libpng-dev (>> > 1.2.0) | libpng12-dev (>> 1.2.0) | libpng2-dev , libtiff3g-dev Dear Adam, Raphaël, Andreas With your explanations, it seems that: - Build Time dependencies are quite limited, - We are going to stick to wxGTK2ud. So, I agree with you all. This is the power of the Internet, we can discuss and arrive to a solution pretty quickly. Thank! Adam: I am not very familiar with conditional statements in RPM specs. Could you give me an example of a conditional statement in an RPM spec? I will work out the dependencies for other systems. About Andreas patches: I hope that they will be integrated quite fast. I don't understand the logic behind all this. It seems "unreal" to keep a broken wxWindows for a long time. Cheers, Jean-Michel
Le Mardi 18 Novembre 2003 09:08, Dave Page a écrit : > For those that don't know, the wx team want all patch submitters to > sign over copyright etc. on their code - this is at request of Borland Dear all, To summarise what Andreas wrote on the wx list (from memory): the individual contributors signing the assignment bear all risks with no gain. My opinion is that Borland needs such an assignment for precise reasons on the long run. For example double-licensing or add-on products. Otherwise, the LGPL-compatible license would suffice. From the statement page, http://www.wxwindows.org/sf/lstatement.htm: << - At the same time, the Board acknowledges that unforeseeable changes and future events could cause a need to revise licensing policy to reflect changed reality, and the Foundation has the right to license the wxWindows code under different licenses or to allow additional, different licensing models. The Board does not currently know of any such events, but cannot rule out the possibility. - Contributions to the wxWindows project will not be licensed under a license (such as the "BSD-style" license) that allows private ports to be distributed. - Contributions to the WxWindows project will remain available under an open source license meeting the requirements of the Debian Free Software Guidelines or the Open Source Definition, with a single exception possible should significant legal problems develop with the Debian Free Software Guidelines or the Open Source Definition. The Board hopes fervently that this exception never arises. >> Unreal !!! In my opinion, I don't see any statement explaining that wxWindows is a common single work. As there is no definition of the word "contribution", the main trunk of wxWindows can be double-licensed and contributions released under a Free license. Or Borland is going to buy developement time and release the work under proprietary licenses. As a result, we will never benefit from Borland "help" and "protection". This is very clear reading the statement page. Now, to understand the wxTeam mind, ask: "Dear Sir, can I cancel the illegal assignment now and sign again in one week?" (the assignment is completely illegal in Europe) And you will probably get the answer: "Thanks for donating your work ... We are working on a new assignment ... Bye, bye" On the list, I have been asking for "public" discussions. I don't see any. As usual, everything is discussed in the back doors. Who is working on a new assignment: Borland? Is Borland the center of the world? People interested in canceling the assignment can visit: http://wiki.wxwindows.org/wiki.pl?Rantings You don't have to be ashamed to say "No". Question : "Can I own your house provided that you live in it for free?" Answer : "No". Cheers, Jean-Michel
Dave Page wrote:
>>>>Still absolutely no, there's not a haze of work in committing
>>>>my patches, not even commenting on it.
>>>>
>>>>
>
>Are you going to bother submitting more now they will probably reject
>them out of hand anyway?
>
>
>
I'll still post patches, if I believe they are necessary. The last
message from Julian about this states "In any event, we will not pursue
copyright assignment to the point where the effort to do so causes
collateral damage and comes at the expense of valuable contributions to
the project. " and "Until we have further legal feedback (...) we will
be accepting patches and bug fixes in the normal way. "
Well, unfortunately the normal way only a single patch I posted in the
last months was accepted (by Robin), some are discussed in an academic
and puristic fashion ("I don't like this", "can't we have some fancy
inheritance way"), and most are simply not discussed at all.
I'm very tired of discussing anything with certain wx people being in
charge of commitments; it's *much* less work maintaining our periodic
snapshots and applying the patches.
Regards,
Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 18 November 2003 09:53 > To: Dave Page > Cc: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] wxGTK2ud BuildRequires dependencies > > I'm very tired of discussing anything with certain wx people > being in charge of commitments; it's *much* less work > maintaining our periodic snapshots and applying the patches. Sad, but if it's easiest... Regards, Dave.
Jean-Michel POURE wrote: >- Contributions to the wxWindows project will not be licensed under a license >(such as the "BSD-style" license) that allows private ports to be >distributed. > > This sounds quite ominous considering that we do exactly that: distribute a private port of wxWindows. Also, depending on the license they choose to distribute wxWindows under, could it cause problems with our product (i.e. GPL vs LGPL)? ahp
Le Mardi 18 Novembre 2003 14:29, Adam H. Pendleton a écrit : > This sounds quite ominous considering that we do exactly that: > distribute a private port of wxWindows. Also, depending on the license > they choose to distribute wxWindows under, could it cause problems with > our product (i.e. GPL vs LGPL)? Dear Adam, I don't know. Probably not very important because the assignements are illegal in most European countries. The most important point to me is that assignments are being put on hold, not canceled. Which means that the members of the board are well-aware that the assignments are not valid in European law, but still refuse to cancel them. Why can't they simply cancel the assignments and propose new/modified ones in one week or more? Everyone would probably sign back. I am tired of all this. Cheers, Jean-Michel
> -----Original Message----- > From: Adam H. Pendleton [mailto:fmonkey@fmonkey.net] > Sent: 18 November 2003 13:30 > To: jm@poure.com > Cc: Dave Page; Andreas Pflug; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] wxGTK2ud BuildRequires dependencies > > Jean-Michel POURE wrote: > > >- Contributions to the wxWindows project will not be > licensed under a > >license (such as the "BSD-style" license) that allows > private ports to > >be distributed. > > > > > This sounds quite ominous considering that we do exactly that: > distribute a private port of wxWindows. Also, depending on > the license they choose to distribute wxWindows under, could > it cause problems with our product (i.e. GPL vs LGPL)? No. They cannot retroactively change the licence on what we already have. Regards, Dave.
Dave Page wrote:
ahp
I was thinking more in terms of future wxWindows snapshots. Are we going to be stuck with what we currently have, or will we be able to integrate future wxWindows code?No. They cannot retroactively change the licence on what we already have.
ahp
Dave Page wrote:
From: Adam H. Pendleton [mailto:fmonkey@fmonkey.net]
Sent: 18 November 2003 15:10
To: Dave Page
Cc: jm@poure.com; Andreas Pflug; pgadmin-hackers@postgresql.org
Subject: Re: [pgadmin-hackers] wxGTK2ud BuildRequires dependenciesNo. They cannot retroactively change the licence on what we already have.I was thinking more in terms of future wxWindows snapshots. Are we going to be stuck with what we currently have, or will we be able to integrate future wxWindows code?
Yes, that may be a problem. IANAL, but I still maintain that even if there is just one of Andreas' patches in the code then they cannot relicence it without his approval (or removing the code and reimplementing it clean-room style) anyway. Same applies to any contributions of course.
This is exactly why the pgAdmin II migration wizard is GPL and a seperate download - it is based on code from pgAdmin I which was GPL, and I couldn't contact all of the contributors.
Regards, Dave.