* Packaging software built with Cygwin @ 2003-02-04 22:34 Jay Maynard 2003-02-04 23:27 ` Igor Pechtchanski 0 siblings, 1 reply; 24+ messages in thread From: Jay Maynard @ 2003-02-04 22:34 UTC (permalink / raw) To: cygwin This is probably an FAQ, but I haven't been able to find any answers on the FAQ page at cygwin.com. I'm the maintainer of Hercules, an emulator for IBM mainframe systems that runs on Linux, Mac OS X, and other Unix-style OSes, and Windows via Cygwin. It's distributed under an OSD-compliant license (the QPL). Currently, we distribute the package without any Cygwin DLLs. Many of our users would like to install Hercules and the necessary DLLs without having to install of Cygwin, or any more than they have to; they're not interested in the Cygwin environment more than is required to run Hercules. Further, since Cygwin is such a moving target, I'd like to be able to give the users an easy way to install the version of the DLLs that corresponds to the version of Cygwin which I used to build the package. Under what terms can I distribute the DLLs? Can I just build up a .zip file with the required files and a copy of the GPL, or will I have to maintain multiple versions of the source code for download as well? (If the latter, I'll probably blow it off entirely; I don't have that kind of disk space.) If I can't distribute the files themselves, is there a simple way to distribute a file that can be fed to setup.exe that will result in only the needed files being downloaded? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with Cygwin 2003-02-04 22:34 Packaging software built with Cygwin Jay Maynard @ 2003-02-04 23:27 ` Igor Pechtchanski 2003-02-05 1:46 ` Jay Maynard 0 siblings, 1 reply; 24+ messages in thread From: Igor Pechtchanski @ 2003-02-04 23:27 UTC (permalink / raw) To: Jay Maynard; +Cc: cygwin On Tue, 4 Feb 2003, Jay Maynard wrote: > This is probably an FAQ, but I haven't been able to find any answers on the > FAQ page at cygwin.com. > > I'm the maintainer of Hercules, an emulator for IBM mainframe systems that > runs on Linux, Mac OS X, and other Unix-style OSes, and Windows via Cygwin. > It's distributed under an OSD-compliant license (the QPL). > > Currently, we distribute the package without any Cygwin DLLs. Many of our > users would like to install Hercules and the necessary DLLs without having > to install of Cygwin, or any more than they have to; they're not interested > in the Cygwin environment more than is required to run Hercules. Further, > since Cygwin is such a moving target, I'd like to be able to give the users > an easy way to install the version of the DLLs that corresponds to the > version of Cygwin which I used to build the package. > > Under what terms can I distribute the DLLs? Can I just build up a .zip file > with the required files and a copy of the GPL, or will I have to maintain > multiple versions of the source code for download as well? (If the latter, > I'll probably blow it off entirely; I don't have that kind of disk space.) > If I can't distribute the files themselves, is there a simple way to > distribute a file that can be fed to setup.exe that will result in only the > needed files being downloaded? Jay, You are aware that linking against the Cygwin DLL automatically makes your software GPL'ed, right? And you are also aware that, if you distribute the Cygwin DLL, you have to distribute it with the source used to build it, correct? However, you don't have to maintain multiple versions of the source code - only the source of the cygwin DLL that you distribute. Thus, if you always update the cygwin DLL on your mirror to the latest available one, you can keep only one (the latest) version of the source there. To answer your last question, setup.exe uses a file called setup.ini, the format of which is described at <http://sources.redhat.com/cygwin-apps/setup.html> (but be sure to use the format for the correct setup version). You can set all the packages you want installed to the "Base" category, so the users can simply point their setup.exe to your mirror and click "Install". However, as the case with NetworkSimplicity's ssh product showed, it's not a good idea to distribute your own cygwin1.dll, especially if you put it in a non-standard location or modify it in any way, as it falls out of date with the "official" cygwin1.dll... But don't despair. You can do even better than that. You don't have to distribute the cygwin DLL from your mirror *at all*. All you need to do is include the "cygwin" package and the others you need in the "requires" list for your ("hercules"?) package, and instruct the users to select one of the standard mirrors along with yours in the setup mirror list. Then, when they select your package to be installed (which would happen automatically if you put it in the "Base" category in your setup.ini), all the packages that it depends upon (i.e., those in its "requires" list) will also be installed. Of course, this will install all of the "standard" "Base" category, but it's not that large, and, chances are, your package depends on most of it anyway. All you'll have to do is make sure that your package works with the latest cygwin1.dll... ;-) Hope this made sense, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ pechtcha@cs.nyu.edu ZZZzz /,`.-'`' -. ;-;;,_ igor@watson.ibm.com |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with Cygwin 2003-02-04 23:27 ` Igor Pechtchanski @ 2003-02-05 1:46 ` Jay Maynard 2003-02-05 2:31 ` Igor Pechtchanski 0 siblings, 1 reply; 24+ messages in thread From: Jay Maynard @ 2003-02-05 1:46 UTC (permalink / raw) To: cygwin; +Cc: Jay Maynard On Tue, Feb 04, 2003 at 06:27:39PM -0500, Igor Pechtchanski wrote: > You are aware that linking against the Cygwin DLL automatically makes your > software GPL'ed, right? Not according to http://cygwin.com/licensing.html: "In accordance with section 10 of the GPL, Red Hat permits programs whose sources are distributed under a license that complies with the Open Source Definition to be linked with libcygwin.a without libcygwin.a itself causing the resulting program to be covered by the GNU GPL." If, despite this, Hercules is somehow covered by the GPL, then our only choice will be to stop distributing a Cygwin version of Hercules, in either source or binary form, as relicensing Hercules under the GPL will never happen. > And you are also aware that, if you distribute the Cygwin DLL, you have to > distribute it with the source used to build it, correct? If that's the case, then I won't distribute the DLLs. I can't afford to keep around multiple versions of the source code corresponding with the multiple versions of the DLLs needed for multiple versions of Hercules. > However, you don't have to maintain multiple versions of the source code - > only the source of the cygwin DLL that you distribute. Thus, if you > always update the cygwin DLL on your mirror to the latest available one, > you can keep only one (the latest) version of the source there. Unfortunately, I keep multiple versions of Hercules around. Since each version of Hercules is compiled against a different version of Cygwin, that means that I need to keep the corresponding DLLs around (since mixing them has proven to be problematical), and that means I need to keep the source, too. > But don't despair. You can do even better than that. You don't have to > distribute the cygwin DLL from your mirror *at all*. All you need to do > is include the "cygwin" package and the others you need in the "requires" > list for your ("hercules"?) package, and instruct the users to select one > of the standard mirrors along with yours in the setup mirror list. Erf. This assumes that the user will use the Cygwin setup routine to install Hercules. So far, there's been no need for that. Hercules is intended as a standalone package which can run with only the required DLLs installed, and none of the rest of Cygwin. The Hercules distribution is a self-extracting .ZIP, self-contained. > all the packages that it depends upon (i.e., those in its "requires" list) > will also be installed. Of course, this will install all of the > "standard" "Base" category, but it's not that large, and, chances are, > your package depends on most of it anyway. All you'll have to do is make > sure that your package works with the latest cygwin1.dll... ;-) In general, when cygwin1.dll changes, Hercules breaks. > Hope this made sense, It did, but I'm not sure there's a lot of help there... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with Cygwin 2003-02-05 1:46 ` Jay Maynard @ 2003-02-05 2:31 ` Igor Pechtchanski 2003-02-05 2:48 ` Jay Maynard 0 siblings, 1 reply; 24+ messages in thread From: Igor Pechtchanski @ 2003-02-05 2:31 UTC (permalink / raw) To: Jay Maynard; +Cc: cygwin On Tue, 4 Feb 2003, Jay Maynard wrote: > On Tue, Feb 04, 2003 at 06:27:39PM -0500, Igor Pechtchanski wrote: > > You are aware that linking against the Cygwin DLL automatically makes your > > software GPL'ed, right? > > Not according to http://cygwin.com/licensing.html: > > "In accordance with section 10 of the GPL, Red Hat permits programs whose > sources are distributed under a license that complies with the Open Source > Definition to be linked with libcygwin.a without libcygwin.a itself causing > the resulting program to be covered by the GNU GPL." > > If, despite this, Hercules is somehow covered by the GPL, then our only > choice will be to stop distributing a Cygwin version of Hercules, in either > source or binary form, as relicensing Hercules under the GPL will never > happen. Now, hold on there, no need to jump the gun. I'm not what you may call "a definitive expert on Cygwin licensing". In fact, whatever that page says surely overrides what I said earlier. > > And you are also aware that, if you distribute the Cygwin DLL, you have to > > distribute it with the source used to build it, correct? I'm pretty sure of this one, but the definitive answer should probably be given by Chris Faylor... > If that's the case, then I won't distribute the DLLs. I can't afford to keep > around multiple versions of the source code corresponding with the multiple > versions of the DLLs needed for multiple versions of Hercules. And why is that? Cygwin DLL is supposed to be backward compatible, either directly or through options. I'd be surprised if any functionality was actually *missing* from a newer cygwin1.dll that was present in an older release (except for the stuff that "nobody used" which got taken out -- if you did use it, you should speak up for including it back in). > > However, you don't have to maintain multiple versions of the source code - > > only the source of the cygwin DLL that you distribute. Thus, if you > > always update the cygwin DLL on your mirror to the latest available one, > > you can keep only one (the latest) version of the source there. > > Unfortunately, I keep multiple versions of Hercules around. Since each > version of Hercules is compiled against a different version of Cygwin, that > means that I need to keep the corresponding DLLs around (since mixing them > has proven to be problematical), and that means I need to keep the source, > too. Remember that linking against some version of libcygwin.a doesn't mean you have to keep to the corresponding version of cygwin1.dll. Since it's loaded dynamically, all you need is for the functions you need to be present in the new DLL. This is generally the case. > > But don't despair. You can do even better than that. You don't have to > > distribute the cygwin DLL from your mirror *at all*. All you need to do > > is include the "cygwin" package and the others you need in the "requires" > > list for your ("hercules"?) package, and instruct the users to select one > > of the standard mirrors along with yours in the setup mirror list. > > Erf. This assumes that the user will use the Cygwin setup routine to install > Hercules. So far, there's been no need for that. Hercules is intended as a > standalone package which can run with only the required DLLs installed, and > none of the rest of Cygwin. The Hercules distribution is a self-extracting > .ZIP, self-contained. Oh. In that case, yes, you'll either need to distribute the cygwin1.dll yourself (and make the source available somewhere) or have the users install the required packages via setup. I assumed you were asking about the latter, hence the answer. The "hercules" package that I was talking about doesn't actually have to contain anything except the dependences (or it could contain a post-install script that would install Hercules from a separately downloaded .ZIP/.EXE or configure an already installed one). You may also want to take a look at CVS HEAD setup's command-line options (only in the source in CVS at the moment, sorry). > > all the packages that it depends upon (i.e., those in its "requires" list) > > will also be installed. Of course, this will install all of the > > "standard" "Base" category, but it's not that large, and, chances are, > > your package depends on most of it anyway. All you'll have to do is make > > sure that your package works with the latest cygwin1.dll... ;-) > > In general, when cygwin1.dll changes, Hercules breaks. Why? > > Hope this made sense, > > It did, but I'm not sure there's a lot of help there... Sorry to hear that. AFAIK, you do have to provide sources for the cygwin1.dll that you distribute. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ pechtcha@cs.nyu.edu ZZZzz /,`.-'`' -. ;-;;,_ igor@watson.ibm.com |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! -- /usr/games/fortune -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with Cygwin 2003-02-05 2:31 ` Igor Pechtchanski @ 2003-02-05 2:48 ` Jay Maynard 2003-02-05 3:32 ` Packaging software built with cygwin Christopher Faylor 0 siblings, 1 reply; 24+ messages in thread From: Jay Maynard @ 2003-02-05 2:48 UTC (permalink / raw) To: cygwin On Tue, Feb 04, 2003 at 09:31:43PM -0500, Igor Pechtchanski wrote: > Now, hold on there, no need to jump the gun. I'm not what you may call "a > definitive expert on Cygwin licensing". In fact, whatever that page says > surely overrides what I said earlier. Okkay...that's what I'd been relying on, and hearing that it wasn't true after all was a shock. I'm happy to hear that my original understanding was correct. > Remember that linking against some version of libcygwin.a doesn't mean you > have to keep to the corresponding version of cygwin1.dll. Since it's > loaded dynamically, all you need is for the functions you need to be > present in the new DLL. This is generally the case. Present *and* working the same or compatibly. Unfortunately, we've found that that's not the case. > Oh. In that case, yes, you'll either need to distribute the cygwin1.dll > yourself (and make the source available somewhere) or have the users > install the required packages via setup. I assumed you were asking about > the latter, hence the answer. The "hercules" package that I was talking > about doesn't actually have to contain anything except the dependences (or > it could contain a post-install script that would install Hercules from a > separately downloaded .ZIP/.EXE or configure an already installed one). Well, if there was an easy way to get setup to do the job, that would be okkay (as long as I could include setup and the necessary control files in the Hercules .ZIP). It sounds like there's not. > > In general, when cygwin1.dll changes, Hercules breaks. > Why? I wish I knew. In general, though, Hercules seems to be a stress test for Cygwin, and we've had lots of folks have trouble by installing later versions fo the DLL than Hercules was built with. There's also a bug right now that causes allocation of three times as much memory as Hercules actually calls for. (I believe that one's already been reported; it really hits Hercules hard, though, as it's not uncommon to have Hercules allocate 256 MB of memory for the emulated system's central storage, and a 768 MB allocation will drive most Windows boxes to their knees.) When that one gets fixed, I'm expecting to have to update my copy of Cygwin, then distribute updated Hercules binaries - which will mean updating the copy of cygwin1.dll needed, which will mean either adding another version of the source (all N megabytes of it), or else pointing people to the Cygwin site... Maybe a better idea is to have a setup option that installs needed DLLs *only*, with no shell, no utility programs, etcetera. > Sorry to hear that. AFAIK, you do have to provide sources for the > cygwin1.dll that you distribute. Damn. You know, this is one reason people stay away from the GPL... (I can go on for hours, and there are undoubtedly folks here who have heard me do it. Anyone who would like to get the whole rant is invited to contact me off-list.) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 2:48 ` Jay Maynard @ 2003-02-05 3:32 ` Christopher Faylor 2003-02-05 13:38 ` Nigel Stewart & Fiona Smith 2003-02-05 17:18 ` Jay Maynard 0 siblings, 2 replies; 24+ messages in thread From: Christopher Faylor @ 2003-02-05 3:32 UTC (permalink / raw) To: cygwin On Tue, Feb 04, 2003 at 08:48:03PM -0600, Jay Maynard wrote: >On Tue, Feb 04, 2003 at 09:31:43PM -0500, Igor Pechtchanski wrote: >>Now, hold on there, no need to jump the gun. I'm not what you may call >>"a definitive expert on Cygwin licensing". In fact, whatever that page >>says surely overrides what I said earlier. > >Okkay...that's what I'd been relying on, and hearing that it wasn't >true after all was a shock. I'm happy to hear that my original >understanding was correct. If you are distributing something that satisfies the "open source" requirement then the program doesn't have to be GPLed. If the QPL is OSD-compliant, as you said, then there is no problem. >>Remember that linking against some version of libcygwin.a doesn't mean >>you have to keep to the corresponding version of cygwin1.dll. Since >>it's loaded dynamically, all you need is for the functions you need to >>be present in the new DLL. This is generally the case. > >Present *and* working the same or compatibly. Unfortunately, we've >found that that's not the case. I sincerely doubt that you've found a problem where something that was available in an older DLL is not available in a newer one. The only case I can think of where this happened is the dropping of //a for /cygdrive/a. >There's also a bug right now that causes allocation of three times as >much memory as Hercules actually calls for. (I believe that one's >already been reported; it really hits Hercules hard, though, as it's >not uncommon to have Hercules allocate 256 MB of memory for the >emulated system's central storage, and a 768 MB allocation will drive >most Windows boxes to their knees.) I'm not aware of any bug report along these lines. I must have missed it. A test case would be welcome. >> Sorry to hear that. AFAIK, you do have to provide sources for the >> cygwin1.dll that you distribute. > >Damn. You know, this is one reason people stay away from the GPL... >(I can go on for hours, and there are undoubtedly folks here who have heard >me do it. Anyone who would like to get the whole rant is invited to contact >me off-list.) Thank you for showing restraint and not going on for hours. However, just in case you need to hear it, it is true that you have to provide the sources for the cygwin DLL if you want to distribute it. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 3:32 ` Packaging software built with cygwin Christopher Faylor @ 2003-02-05 13:38 ` Nigel Stewart & Fiona Smith 2003-02-05 14:11 ` Christopher Faylor 2003-02-05 17:18 ` Jay Maynard 1 sibling, 1 reply; 24+ messages in thread From: Nigel Stewart & Fiona Smith @ 2003-02-05 13:38 UTC (permalink / raw) To: cygwin > However, just in case you need to hear it, it is true that you have to > provide the sources for the cygwin DLL if you want to distribute it. There is always the MingW option via -mno-cygwin. (Perhaps stating the obvious, but just in case...) http://www.mingw.org/ Regards, Nigel Stewart -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 13:38 ` Nigel Stewart & Fiona Smith @ 2003-02-05 14:11 ` Christopher Faylor 2003-02-05 14:14 ` Jay Maynard 0 siblings, 1 reply; 24+ messages in thread From: Christopher Faylor @ 2003-02-05 14:11 UTC (permalink / raw) To: cygwin On Thu, Feb 06, 2003 at 12:39:45AM +1100, Nigel Stewart & Fiona Smith wrote: >>However, just in case you need to hear it, it is true that you have to >>provide the sources for the cygwin DLL if you want to distribute it. > >There is always the MingW option via -mno-cygwin. (Perhaps stating the >obvious, but just in case...) > >http://www.mingw.org/ I assume that the software in question actually uses the UNIX api. Mingw has only a very small subset of this available. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 14:11 ` Christopher Faylor @ 2003-02-05 14:14 ` Jay Maynard 0 siblings, 0 replies; 24+ messages in thread From: Jay Maynard @ 2003-02-05 14:14 UTC (permalink / raw) To: cygwin On Wed, Feb 05, 2003 at 09:12:02AM -0500, Christopher Faylor wrote: > On Thu, Feb 06, 2003 at 12:39:45AM +1100, Nigel Stewart & Fiona Smith wrote: > >>However, just in case you need to hear it, it is true that you have to > >>provide the sources for the cygwin DLL if you want to distribute it. > >There is always the MingW option via -mno-cygwin. (Perhaps stating the > >obvious, but just in case...) > >http://www.mingw.org/ > I assume that the software in question actually uses the UNIX api. Mingw has > only a very small subset of this available. Hercules uses large parts of the Linux API. (It was originally developed on Linux; while it'll run on most Unix systems, there are some functions, most notably SCSI tape support, that only work on Linux.) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 3:32 ` Packaging software built with cygwin Christopher Faylor 2003-02-05 13:38 ` Nigel Stewart & Fiona Smith @ 2003-02-05 17:18 ` Jay Maynard 2003-02-05 17:30 ` Nigel Stewart & Fiona Smith 2003-02-05 17:54 ` Christopher Faylor 1 sibling, 2 replies; 24+ messages in thread From: Jay Maynard @ 2003-02-05 17:18 UTC (permalink / raw) To: cygwin On Tue, Feb 04, 2003 at 10:32:46PM -0500, Christopher Faylor wrote: > On Tue, Feb 04, 2003 at 08:48:03PM -0600, Jay Maynard wrote: > >On Tue, Feb 04, 2003 at 09:31:43PM -0500, Igor Pechtchanski wrote: > >>Remember that linking against some version of libcygwin.a doesn't mean > >>you have to keep to the corresponding version of cygwin1.dll. Since > >>it's loaded dynamically, all you need is for the functions you need to > >>be present in the new DLL. This is generally the case. > >Present *and* working the same or compatibly. Unfortunately, we've > >found that that's not the case. > I sincerely doubt that you've found a problem where something that was > available in an older DLL is not available in a newer one. The only > case I can think of where this happened is the dropping of //a for > /cygdrive/a. There are numerous bug reports in the Hercules mailing list archives from folks who have tried to run Hercules with a different version of cygwin1.dll than the one Hercules was built against. In every case, installing the version that Hercules was built against corrected the problem. It may be intended to be upward compatible, but that's not our experience. > >There's also a bug right now that causes allocation of three times as > >much memory as Hercules actually calls for. (I believe that one's > >already been reported; it really hits Hercules hard, though, as it's > >not uncommon to have Hercules allocate 256 MB of memory for the > >emulated system's central storage, and a 768 MB allocation will drive > >most Windows boxes to their knees.) > I'm not aware of any bug report along these lines. I must have missed > it. > A test case would be welcome. I've asked the Hercules developer community, several of whom are much more familiar with development under Cygwin than I am, to generate a test case and report the bug. I had thought it had been reported, but it apparently has not been. > However, just in case you need to hear it, it is true that you have to > provide the sources for the cygwin DLL if you want to distribute it. I have stopped distributing the Cygwin DLL entirely, since meeting this requirement would impose larger requirements for disk space and/or time than I can afford. (See how the GPL has improved sharing of programs! Pfaugh.) Of the five DLLs that Hercules needs (cygwin1.dll, cygintl-2.dll, cygiconv-2.dll, cygbz2-1.dll, and cygz.dll), only one is GPLed. This imposes requirements on distribution of the complete package that do not apply to the other platforms that Hercules is distributed for. This is hardly going to make porting packages from Linux to Windows easier. I've considered, and rejected, the idea of distributing my own setup.ini file. The problem is that it seems to be as much of a moving target as Cygwin itself. I would suggest that, if it is desired to promote the development of applications on the Cygwin platform, serious consideration be made to making it as simple as possible to install only those portions of Cygwin that the application requires. This means just the necessary DLLs, without all of the interactive use baggage. Right now, that's nearly impossible. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 17:18 ` Jay Maynard @ 2003-02-05 17:30 ` Nigel Stewart & Fiona Smith 2003-02-05 17:52 ` Max Bowsher 2003-02-05 18:19 ` Christopher Faylor 2003-02-05 17:54 ` Christopher Faylor 1 sibling, 2 replies; 24+ messages in thread From: Nigel Stewart & Fiona Smith @ 2003-02-05 17:30 UTC (permalink / raw) To: Jay Maynard, cygwin > I would suggest that, if it is desired to promote the development of > applications on the Cygwin platform, serious consideration be made to making > it as simple as possible to install only those portions of Cygwin that the > application requires. This means just the necessary DLLs, without all of the > interactive use baggage. Right now, that's nearly impossible. Technically, the ideal solution would be to link against a set of static libraries. Therefore requiring no extra install at all. No DLL hell, no tech support, no "Cygwin is the problem" perception. However, is it feasible for the Cygwin project to make this exception for the sake of utility? This is the same reason I find myself experimenting with mingw, I would like to use Cygwin as the devel platform and target native binaries, or at least non Cygwin-DLL dependent binaries... My 0.02, no offence intended to GPL oriented people... Regards, Nigel Stewart -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 17:30 ` Nigel Stewart & Fiona Smith @ 2003-02-05 17:52 ` Max Bowsher 2003-02-06 13:17 ` Nigel Stewart & Fiona Smith 2003-02-05 18:19 ` Christopher Faylor 1 sibling, 1 reply; 24+ messages in thread From: Max Bowsher @ 2003-02-05 17:52 UTC (permalink / raw) To: Nigel Stewart & Fiona Smith, Jay Maynard, cygwin Nigel Stewart & Fiona Smith wrote: >> I would suggest that, if it is desired to promote the development of >> applications on the Cygwin platform, serious consideration be made >> to making it as simple as possible to install only those portions of >> Cygwin that the application requires. This means just the necessary >> DLLs, without all of the interactive use baggage. Right now, that's >> nearly impossible. If someone wishes to volunteer to work towards that... > Technically, the ideal solution would be to link against a set > of static libraries. Therefore requiring no extra install at > all. No DLL hell, no tech support, no "Cygwin is the problem" > perception. I believe this would require some significant work to make it possible. > However, is it feasible for the Cygwin project to > make this exception for the sake of utility? If you are talking about making cygwin static-capable - see above - lots of work. Also, the most experienced Cygwin coders won't be that interested, because they *like* Cygwin-the-enviroment, as opposed to Cygwin-for-the-sake-of-one-program. Also, there is the side benefit that it is *much* easier to spot GPL violations this way. > This is the same reason I find myself experimenting with > mingw, I would like to use Cygwin as the devel platform > and target native binaries, or at least non Cygwin-DLL > dependent binaries... You can - they just can't use the unix APIs. I use Cygwin for all my compilation needs, Cygwin-linked, or native Win32. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 17:52 ` Max Bowsher @ 2003-02-06 13:17 ` Nigel Stewart & Fiona Smith 2003-02-06 13:43 ` Max Bowsher 0 siblings, 1 reply; 24+ messages in thread From: Nigel Stewart & Fiona Smith @ 2003-02-06 13:17 UTC (permalink / raw) To: cygwin >>Technically, the ideal solution would be to link against a set >>of static libraries. > > I believe this would require some significant work to make it possible. OK, it feels like we're getting into a circular argument. I am not insisting that anyone do any particular thing to Cygwin. My intention is to raise a perspective on a potential use of Cygwin which may or may not be desirable, feasible, popular or supported by the Cygwin community. > Also, the most experienced Cygwin coders won't be that interested, > because they *like* Cygwin-the-enviroment, as opposed to > Cygwin-for-the-sake-of-one-program. Fair enough, I like using Cygwin-the-environment, but feel restricted in terms of deploying binaries into a non-cygwin environment. Even though the Cygwin installation procedure has been greatly enhanced and streamlined, in my opinion Cygwin is too heavy-weight for an average computer user to install and administer. So, if this is outside the scope of what Cygwin is for, then that is a reasonable answer... I'm finding mingw is working quite well (perhaps, the best of both worlds) but would prefer to keep my code clean (POSIX) rather than infected with extraneous win32 calls... > You can - they just can't use the unix APIs. > I use Cygwin for all my compilation needs, Cygwin-linked, or native Win32. So rather than upsetting the Cygwin faithful, would it be better to expand the support POSIX subset for mingw, rather than making Cygwin an easily managed light-weight dependency. Regards, Nigel Stewart -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-06 13:17 ` Nigel Stewart & Fiona Smith @ 2003-02-06 13:43 ` Max Bowsher 2003-02-06 14:05 ` Nigel Stewart & Fiona Smith 0 siblings, 1 reply; 24+ messages in thread From: Max Bowsher @ 2003-02-06 13:43 UTC (permalink / raw) To: Nigel Stewart & Fiona Smith, cygwin Nigel Stewart & Fiona Smith wrote: > Fair enough, I like using Cygwin-the-environment, but > feel restricted in terms of deploying binaries into > a non-cygwin environment. Even though the Cygwin > installation procedure has been greatly enhanced and > streamlined, in my opinion Cygwin is too heavy-weight for > an average computer user to install and administer. I agree that Cygwin is a very bulky solution if you only want to be able to run one program (ssh, or rsync, for example). > So rather than upsetting the Cygwin faithful, would > it be better to expand the support POSIX subset for > mingw, rather than making Cygwin an easily managed > light-weight dependency. Those are 2 different paths to the same goal. However, if you worked at it from the Cygwin end, the resulting code would be GPL. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-06 13:43 ` Max Bowsher @ 2003-02-06 14:05 ` Nigel Stewart & Fiona Smith 0 siblings, 0 replies; 24+ messages in thread From: Nigel Stewart & Fiona Smith @ 2003-02-06 14:05 UTC (permalink / raw) To: Max Bowsher, cygwin > Those are 2 different paths to the same goal. Just to clarify my "goal".... Painless development and deployment of software across Linux and Windows. Both open-source and commercial. Which, for me is already 95% there with Cygwin, and possibly even 98% there with Cygwin+Mingw.... Cheers, Nigel Stewart (Perhaps time to delve more into MingW :-) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 17:30 ` Nigel Stewart & Fiona Smith 2003-02-05 17:52 ` Max Bowsher @ 2003-02-05 18:19 ` Christopher Faylor 1 sibling, 0 replies; 24+ messages in thread From: Christopher Faylor @ 2003-02-05 18:19 UTC (permalink / raw) To: cygwin On Thu, Feb 06, 2003 at 04:31:15AM +1100, Nigel Stewart & Fiona Smith wrote: >>I would suggest that, if it is desired to promote the development of >>applications on the Cygwin platform, serious consideration be made to >>making it as simple as possible to install only those portions of >>Cygwin that the application requires. This means just the necessary >>DLLs, without all of the interactive use baggage. Right now, that's >>nearly impossible. > >Technically, the ideal solution would be to link against a set of >static libraries. Therefore requiring no extra install at all. No DLL >hell, no tech support, no "Cygwin is the problem" perception. However, >is it feasible for the Cygwin project to make this exception for the >sake of utility? It isn't a question of "making an exception". It's a question of someone doing the work. I have no interest in it and it seems like no one else is either since this has come up repeatedly in the last five years. If you are asking if we'd make an exception and not GPL something because it is statically linked then the answer to that is "no". Static linking doesn't change this scenario a whit. >This is the same reason I find myself experimenting with mingw, I would >like to use Cygwin as the devel platform and target native binaries, or >at least non Cygwin-DLL dependent binaries... If you want binaries that don't use the UNIX API then of course you should use MinGW. That has nothing to do with with licensing issues. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 17:18 ` Jay Maynard 2003-02-05 17:30 ` Nigel Stewart & Fiona Smith @ 2003-02-05 17:54 ` Christopher Faylor 2003-02-05 18:55 ` Jay Maynard 1 sibling, 1 reply; 24+ messages in thread From: Christopher Faylor @ 2003-02-05 17:54 UTC (permalink / raw) To: cygwin On Wed, Feb 05, 2003 at 11:18:22AM -0600, Jay Maynard wrote: >On Tue, Feb 04, 2003 at 10:32:46PM -0500, Christopher Faylor wrote: >> On Tue, Feb 04, 2003 at 08:48:03PM -0600, Jay Maynard wrote: >> >On Tue, Feb 04, 2003 at 09:31:43PM -0500, Igor Pechtchanski wrote: >> >>Remember that linking against some version of libcygwin.a doesn't mean >> >>you have to keep to the corresponding version of cygwin1.dll. Since >> >>it's loaded dynamically, all you need is for the functions you need to >> >>be present in the new DLL. This is generally the case. >> >Present *and* working the same or compatibly. Unfortunately, we've >> >found that that's not the case. >> I sincerely doubt that you've found a problem where something that was >> available in an older DLL is not available in a newer one. The only >> case I can think of where this happened is the dropping of //a for >> /cygdrive/a. > >There are numerous bug reports in the Hercules mailing list archives from >folks who have tried to run Hercules with a different version of >cygwin1.dll than the one Hercules was built against. In every case, >installing the version that Hercules was built against corrected the >problem. > >It may be intended to be upward compatible, but that's not our experience. Ok. I'm not going to start scouring random other mailing lists for cygwin bug reports so I suppose this situation will continue In absence of any details, it's fruitless to carry this discussion any further. >>However, just in case you need to hear it, it is true that you have to >>provide the sources for the cygwin DLL if you want to distribute it. > >I have stopped distributing the Cygwin DLL entirely, since meeting this >requirement would impose larger requirements for disk space and/or time >than I can afford. (See how the GPL has improved sharing of programs! >Pfaugh.) Hmm. Looks like you just couldn't resist, huh? >Of the five DLLs that Hercules needs (cygwin1.dll, cygintl-2.dll, >cygiconv-2.dll, cygbz2-1.dll, and cygz.dll), only one is GPLed. This >imposes requirements on distribution of the complete package that do >not apply to the other platforms that Hercules is distributed for. >This is hardly going to make porting packages from Linux to Windows >easier. The source tarball for cygwin is 4.6M. I don't understand why this is a huge hardship but, frankly, I don't really care. >I've considered, and rejected, the idea of distributing my own >setup.ini file. The problem is that it seems to be as much of a moving >target as Cygwin itself. A setup.ini with just the cygwin DLL in it seems pretty simple. Btw, perhaps it is not your intention, but I catch a whiff of innuendo here makes me wonder if you're really asking for help or just here to make some statements. >I would suggest that, if it is desired to promote the development of >applications on the Cygwin platform, serious consideration be made to >making it as simple as possible to install only those portions of >Cygwin that the application requires. This means just the necessary >DLLs, without all of the interactive use baggage. Right now, that's >nearly impossible. Supporting other people's distributions is not a core focus of setup.exe. However, if this is important to you it should be pretty easy for you to submit patches to do what you want. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 17:54 ` Christopher Faylor @ 2003-02-05 18:55 ` Jay Maynard 2003-02-05 20:43 ` Christopher Faylor ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Jay Maynard @ 2003-02-05 18:55 UTC (permalink / raw) To: cygwin On Wed, Feb 05, 2003 at 12:55:43PM -0500, Christopher Faylor wrote: > On Wed, Feb 05, 2003 at 11:18:22AM -0600, Jay Maynard wrote: > >It may be intended to be upward compatible, but that's not our experience. > Ok. I'm not going to start scouring random other mailing lists for > cygwin bug reports so I suppose this situation will continue In absence > of any details, it's fruitless to carry this discussion any further. Fine by me; it's been over the past year or so, as well, so bug reports at this point will be of limited use. However, are you saying that if we encounter problems with Hercules 2.17 (built against Cygwin 1.3.19) running with, say, Cygwin 1.3.22, you'll take a bug report on that and fix the problem? BTW, I'm not the only one to have this problem; there's a message on the Hercules list that was posted in reply to my announcement that I would no longer distribute the DLLs saying that his company got away from Cygwin for exactly that reason. (I'll forward it, if you like.) > Hmm. Looks like you just couldn't resist, huh? No, I couldn't. > The source tarball for cygwin is 4.6M. I don't understand why this > is a huge hardship but, frankly, I don't really care. 4.6 MB times how many versions will I need to keep around? Before I removed them from the Hercules site, I had four sets of the Cygwin DLLs, corresponding to four versions of Hercules they were needed for. Every time I release a new version of Hercules, that's another source tarball I'd need. Further, is that tarball guaranteed to satisfy the requirement to distribute the source code for that version? Is everything that's needed in that one tarball? If so, can I get that in writing, so that if someone comes along later and alleges a GPL violation, I can say, "No, Red Hat says that distributing this tarball is sufficient."? Otherwise, I'd have to keep around the entire Cygwin source, just to make sure I included everything that was necessary. I'm sure that's more than 4.6 MB. > A setup.ini with just the cygwin DLL in it seems pretty simple. True. OTOH, when setup.exe changes, the format of that file is subject to change (see Igor's warning in the message where he first suggested that). I can insulate myself from that by distributing setup.exe, but then I'm back in the same boat of making sure that I distribute the source code that's used to generate it. > Btw, perhaps it is not your intention, but I catch a whiff of innuendo > here makes me wonder if you're really asking for help or just here to > make some statements. I'm looking for a way to make it simple for Hercules users to install the needed support for the Cygwin version without violating any licenses, without having to keep multiple megabytes of multiple versions of source code around that nobody will ever download, and without making them install multiple megabytes of Cygwin environment they have no interest in using. It's no secret that I've opposed the GPL for many years. (I invented the term GPV in 1989.) However, I'm stuck with it, so I'm trying to do what I need done without violating it. That doesn't mean I have to like it. > Supporting other people's distributions is not a core focus of > setup.exe. However, if this is important to you it should be pretty > easy for you to submit patches to do what you want. I'll take a look in my copious free time. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 18:55 ` Jay Maynard @ 2003-02-05 20:43 ` Christopher Faylor 2003-02-05 21:41 ` Robert Collins 2003-02-06 9:59 ` Ronald Landheer-Cieslak 2 siblings, 0 replies; 24+ messages in thread From: Christopher Faylor @ 2003-02-05 20:43 UTC (permalink / raw) To: cygwin Cutting through the noise: 1) In an open source, volunteer project there are no guarantees that anything will be fixed. We do the best we can given our interests and time. However, you should be reporting cygwin bugs to the cygwin mailing list if you want the possibility of getting them fixed. You can use http://cygwin.com/bugs.html as a guide for how to submit bugs. No, I don't care to hear from the multitude of people in your project who are leaving cygwin because of all of their serious problems. Good luck to them with MinGW, Interix, U/WIN, or whereever they've decided to use. I'm only interested in actual bug reports. I can do something with a bug report. I can't do a single thing with "Every cygwin release breaks Hercules" or "Cygwin has too many bugs, so I'm giving up on it". I'm sure you know that neither of the above are bug reports. They are basically just noise. I don't have enough "copious spare time" to devote to wheedling details out of people. YMMV. 2) I am not trying to blindside you by suggesting that you can distribute the Cygwin source tar ball so that Red Hat lawyers could go after you later. No, I'm not going to give you anything in writing. I'm not going to set that precedent. There are plenty of sites on the internet who are distributing the source tarballs without an official signature from Red Hat. 3) I find all GPL discussions uninteresting and unproductive. I really really hope you can avoid any more harping on this. 4) I'm sorry that none of the suggestions put forth here are satisfactory to you. I'm out of ideas, so that will probably be it for me in this thread unless there is a specific bug report that needs addressing. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 18:55 ` Jay Maynard 2003-02-05 20:43 ` Christopher Faylor @ 2003-02-05 21:41 ` Robert Collins 2003-02-06 9:59 ` Ronald Landheer-Cieslak 2 siblings, 0 replies; 24+ messages in thread From: Robert Collins @ 2003-02-05 21:41 UTC (permalink / raw) To: Jay Maynard; +Cc: cygwin [-- Attachment #1: Type: text/plain, Size: 1475 bytes --] On Thu, 2003-02-06 at 05:55, Jay Maynard wrote: > > A setup.ini with just the cygwin DLL in it seems pretty simple. > > True. OTOH, when setup.exe changes, the format of that file is subject to > change (see Igor's warning in the message where he first suggested that). I > can insulate myself from that by distributing setup.exe, but then I'm back > in the same boat of making sure that I distribute the source code that's > used to generate it. We're in that boat too. (I'm the setup.exe maintainer). And we don't break compatability at any significant speed - we *alway* deprecate for at least one release, to allow third party sites (ones with their own custom setup.ini) to catch up in their own time. For instance, uncompressed setup.ini's are still supported, as a fallback when .bz2 compressed ones are not found. As far as distributing multiple versions of setup.exe's source, it's easy: only distribute the current version. You don't need to distribute old versions, because you can just update your setup.ini. > > Supporting other people's distributions is not a core focus of > > setup.exe. However, if this is important to you it should be pretty > > easy for you to submit patches to do what you want. > > I'll take a look in my copious free time. Do that. There is very little that would need doing, if I intuit your needs correctly. Rob -- GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-05 18:55 ` Jay Maynard 2003-02-05 20:43 ` Christopher Faylor 2003-02-05 21:41 ` Robert Collins @ 2003-02-06 9:59 ` Ronald Landheer-Cieslak 2003-02-06 13:24 ` Jay Maynard 2 siblings, 1 reply; 24+ messages in thread From: Ronald Landheer-Cieslak @ 2003-02-06 9:59 UTC (permalink / raw) To: Jay Maynard; +Cc: cygwin The way I read GPL (but please correct me if I'm wrong) you should be able to write a fork off the current Setup that installs the Hercules and gets the Cygwin from one of the mirrors (of which you can download the list at the time of installing from cygwin.com). Technically, you would not be distributing Cygwin (because you would be using Red Hat's own distribution) but the effect would be the same. Your remaining problem would be that Cygwin is a "moving target" as you say, but Cygwin doesn't move all *that* quickly either, does it? I mean, you don't build Hercules against the latest snapshot do you? Of course, I have no idea how extensively you use the Cygwin API but my (arguably little, juding by the size of my projects vs yours) experience has always been that if you stick to POSIX compliance, Cygwin does the job quite nicely (and patches to Cygwin are usually welcome in case of error, provided you have a copyright waiver which I don't have). As for GPL rants: I'd be interested (off-list) in hearing your reasons for being against GPL, and even more in what alternatives you would propose. Greetz! rlc On Wed, 5 Feb 2003, Jay Maynard wrote: > On Wed, Feb 05, 2003 at 12:55:43PM -0500, Christopher Faylor wrote: > > On Wed, Feb 05, 2003 at 11:18:22AM -0600, Jay Maynard wrote: > > >It may be intended to be upward compatible, but that's not our experience. > > Ok. I'm not going to start scouring random other mailing lists for > > cygwin bug reports so I suppose this situation will continue In absence > > of any details, it's fruitless to carry this discussion any further. > > Fine by me; it's been over the past year or so, as well, so bug reports at > this point will be of limited use. However, are you saying that if we > encounter problems with Hercules 2.17 (built against Cygwin 1.3.19) running > with, say, Cygwin 1.3.22, you'll take a bug report on that and fix the > problem? > > BTW, I'm not the only one to have this problem; there's a message on the > Hercules list that was posted in reply to my announcement that I would no > longer distribute the DLLs saying that his company got away from Cygwin for > exactly that reason. (I'll forward it, if you like.) > > > Hmm. Looks like you just couldn't resist, huh? > > No, I couldn't. > > > The source tarball for cygwin is 4.6M. I don't understand why this > > is a huge hardship but, frankly, I don't really care. > > 4.6 MB times how many versions will I need to keep around? Before I removed > them from the Hercules site, I had four sets of the Cygwin DLLs, > corresponding to four versions of Hercules they were needed for. Every time > I release a new version of Hercules, that's another source tarball I'd need. > > Further, is that tarball guaranteed to satisfy the requirement to distribute > the source code for that version? Is everything that's needed in that one > tarball? If so, can I get that in writing, so that if someone comes along > later and alleges a GPL violation, I can say, "No, Red Hat says that > distributing this tarball is sufficient."? Otherwise, I'd have to keep > around the entire Cygwin source, just to make sure I included everything > that was necessary. I'm sure that's more than 4.6 MB. > > > A setup.ini with just the cygwin DLL in it seems pretty simple. > > True. OTOH, when setup.exe changes, the format of that file is subject to > change (see Igor's warning in the message where he first suggested that). I > can insulate myself from that by distributing setup.exe, but then I'm back > in the same boat of making sure that I distribute the source code that's > used to generate it. > > > Btw, perhaps it is not your intention, but I catch a whiff of innuendo > > here makes me wonder if you're really asking for help or just here to > > make some statements. > > I'm looking for a way to make it simple for Hercules users to install the > needed support for the Cygwin version without violating any licenses, > without having to keep multiple megabytes of multiple versions of source > code around that nobody will ever download, and without making them install > multiple megabytes of Cygwin environment they have no interest in using. > > It's no secret that I've opposed the GPL for many years. (I invented the > term GPV in 1989.) However, I'm stuck with it, so I'm trying to do what I > need done without violating it. That doesn't mean I have to like it. > > > Supporting other people's distributions is not a core focus of > > setup.exe. However, if this is important to you it should be pretty > > easy for you to submit patches to do what you want. > > I'll take a look in my copious free time. > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin 2003-02-06 9:59 ` Ronald Landheer-Cieslak @ 2003-02-06 13:24 ` Jay Maynard 0 siblings, 0 replies; 24+ messages in thread From: Jay Maynard @ 2003-02-06 13:24 UTC (permalink / raw) To: cygwin On Thu, Feb 06, 2003 at 10:34:36AM +0100, Ronald Landheer-Cieslak wrote: > The way I read GPL (but please correct me if I'm wrong) you should be able > to write a fork off the current Setup that installs the Hercules and gets > the Cygwin from one of the mirrors (of which you can download the list at > the time of installing from cygwin.com). Technically, you would not be > distributing Cygwin (because you would be using Red Hat's own > distribution) but the effect would be the same. I've got no philosophical problems with submitting changes to setup.exe to the maintainers for inclusion in the distributed program. My only interest in all of this in the first place is to enable users to easily install Hercules; I'm not, and have no intention of becoming, a Cygwin developer. > Your remaining problem would be that Cygwin is a "moving target" as you > say, but Cygwin doesn't move all *that* quickly either, does it? I mean, > you don't build Hercules against the latest snapshot do you? Hercules is built against the latest production release of Cygwin at the time it is released. That version has changed from 1.3.10 to 1.3.19 in the time between the last two releases of Hercules (2.16.5, released on 8 July 2002, and 2.17, released on 1 February 2003). That counts as a moving target. In general, Hercules major releases happen every 6 to 9 months. > Of course, I have no idea how extensively you use the Cygwin API but my > (arguably little, juding by the size of my projects vs yours) experience > has always been that if you stick to POSIX compliance, Cygwin does the job > quite nicely (and patches to Cygwin are usually welcome in case of error, > provided you have a copyright waiver which I don't have). Cygwin does the job well enough, or else we wouldn't be having this discussion. Were it not for inter-version incompatibilities, I'd pick a version of the DLLs to use, keep one source tarball (and a copy of the email saying that was sufficient to meet the demands of GPL compliance) around, and be done with it. Unfortunately, that's not the way it has proven to work. > As for GPL rants: I'd be interested (off-list) in hearing your reasons for > being against GPL, and even more in what alternatives you would propose. Sent. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin @ 2003-02-05 20:44 Franz Wolfhagen 0 siblings, 0 replies; 24+ messages in thread From: Franz Wolfhagen @ 2003-02-05 20:44 UTC (permalink / raw) To: cygwin One of the things that your users have been bitten of with the newer cygwin1.dll is that they impose a stronger authentication mechanism (ntsec is on per default). This is often brought up here by users that are have upgraded their version. Please (re)consider supporting a cygwin package via the cygwin setup - I can assure you that your application will be much more visible if you are able to do that (or have somebody to support you doing that) - I would love to have a maintained hercules environment on my machine allthough the license problems for Z/OS in my environment would make me violate the Z/OS license (now compare that to the GBL ;-).... If I find the time I will try to install Hercules on my Cygwin environment which is allways kept on the (b)leeding edge...- - please do not leave us too soon.... Med venlig hilsen / Regards Franz Wolfhagen -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Packaging software built with cygwin @ 2003-02-06 13:24 Joshua Daniel Franklin 0 siblings, 0 replies; 24+ messages in thread From: Joshua Daniel Franklin @ 2003-02-06 13:24 UTC (permalink / raw) To: jmaynard, cygwin > > The source tarball for cygwin is 4.6M. I don't understand why this > > is a huge hardship but, frankly, I don't really care. > 4.6 MB times how many versions will I need to keep around? Before I removed > them from the Hercules site, I had four sets of the Cygwin DLLs, > corresponding to four versions of Hercules they were needed for. Every time > I release a new version of Hercules, that's another source tarball I'd need. I realize this is pretty late in the discussion, but I have a suggestion that might work. Online, you could distribute only the latest, known-working version of Hercules with cygwin1.dll and the source to that version of cygwin1.dll--no, you don't need the source to gcc (that's used to build it) nor the source to TeX (that's used for the documentation) nor the source to Linux (that's also GPL'd), why would you? For older versions, you could put a note stating that due to online space requirements older cygwin versions are not available online. If you don't have offline space issues, you could keep an archive around on your personal machine (or on CD or tape or punch-card or wherever) for emergencies. Hopefully in the future some good bug reports can be used to track down whatever is causing the backward-compaitibility to break, so this would no longer be necessary. Hope this helps and have a nice day. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2003-02-06 14:05 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-02-04 22:34 Packaging software built with Cygwin Jay Maynard 2003-02-04 23:27 ` Igor Pechtchanski 2003-02-05 1:46 ` Jay Maynard 2003-02-05 2:31 ` Igor Pechtchanski 2003-02-05 2:48 ` Jay Maynard 2003-02-05 3:32 ` Packaging software built with cygwin Christopher Faylor 2003-02-05 13:38 ` Nigel Stewart & Fiona Smith 2003-02-05 14:11 ` Christopher Faylor 2003-02-05 14:14 ` Jay Maynard 2003-02-05 17:18 ` Jay Maynard 2003-02-05 17:30 ` Nigel Stewart & Fiona Smith 2003-02-05 17:52 ` Max Bowsher 2003-02-06 13:17 ` Nigel Stewart & Fiona Smith 2003-02-06 13:43 ` Max Bowsher 2003-02-06 14:05 ` Nigel Stewart & Fiona Smith 2003-02-05 18:19 ` Christopher Faylor 2003-02-05 17:54 ` Christopher Faylor 2003-02-05 18:55 ` Jay Maynard 2003-02-05 20:43 ` Christopher Faylor 2003-02-05 21:41 ` Robert Collins 2003-02-06 9:59 ` Ronald Landheer-Cieslak 2003-02-06 13:24 ` Jay Maynard 2003-02-05 20:44 Franz Wolfhagen 2003-02-06 13:24 Joshua Daniel Franklin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).