Re: Recent upgrade to wish leads to a problem
On 3/2/2012 1:33 PM, Matt Seitz (matseitz) wrote: From: Christopher Faylor For the record, I don't think Yaakov, Corinna, or I are really interested in spending our time adding some sort of suggestion mechanism to setup.exe. This would have ramifications both for setup.exe, for the script which updates setup.ini, and for the genini script. It would likely be a fair amount of work. I thought I had sometimes seen Setup display a dialog box that said something like The package you have selected requires the following additional packages, with a check box saying Install these packages (RECOMMENDED). What triggers that dialog box to appear? You get that when you've deselected a package that's a requirement for another package you selected. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Fri, Mar 02, 2012 at 10:31:54PM -0600, Robert Miles wrote: On 3/2/2012 11:43 AM, Christopher Faylor wrote: On Fri, Mar 02, 2012 at 01:11:49AM -0600, Robert Miles wrote: On 3/1/2012 1:38 PM, Jeremy Bopp wrote: On 03/01/2012 01:05 PM, Eric Blake wrote: On 03/01/2012 10:53 AM, Matt Seitz (matseitz) wrote: [snip] I suspect not, but I would like to see such recommended and/or suggested packages. Back when I was using Cygwin gcc so I could learn C, m4 was not installed along with it, and I believe that m4 should at least be shown as a recommended package to go along with gcc. There is no reason to include m4 as a gcc dependency if you are trying to learn C. This would not even be a case of a suggestion. If you needed m4 for some reason (maybe for autoconf/automake) that really would be a case where you need to install m4 separately. You can use gcc quite happily without having m4 installed. For the record, I don't think Yaakov, Corinna, or I are really interested in spending our time adding some sort of suggestion mechanism to setup.exe. This would have ramifications both for setup.exe, for the script which updates setup.ini, and for the genini script. It would likely be a fair amount of work. Given the fact that this has come up repeatedly over the years I am pretty sure that repeated suggestions that setup.exe should be modified to do this are likely not going to have any effect. The examples I used for learning C all used #include, and therefore required m4 in order to compile. I believe gcc gave an error message in this case showing what was missing, and therefore did not slow down the learning process too much. Sorry but m4 has nothing to do with #include. I don't doubt that you saw some error that mentioned m4 but it undoubtedly came from a package which used m4. gcc itself does not use m4 to expand #include. #include files are expanded by gcc automatically without the help of an external program like m4. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
Greetings, Achim Gratz! As long as setup.exe doesn't handle recommendations, how about having an (empty) package X-application (or whatever better name you come up with) that all such applications depend on? I'm still not sure how to get the actual warning to the user, but for starters the postinstall script could fail when it doesn't find the Cygwin X server and leave a file that cygcheck looks for otherwise. Nothing stops you from showing a warning/opening a README to the user in the same postinstall script. And there's more, and better, ways to check for configured X server, I bet. -- WBR, Andrey Repin (anrdae...@freemail.ru) 02.03.2012, 16:22 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Fri, Mar 02, 2012 at 01:11:49AM -0600, Robert Miles wrote: On 3/1/2012 1:38 PM, Jeremy Bopp wrote: On 03/01/2012 01:05 PM, Eric Blake wrote: On 03/01/2012 10:53 AM, Matt Seitz (matseitz) wrote: You don't think that Setup telling the user package xyz requires package xinit might at least tip off some users that running xyz now requires starting an X server? Even if it doesn't reduce the questions, would it at least reduce the problem of users now having to run Setup a second time to download and install the xinit package? While I can't control whether Yaakov adds xinit as a dependency to tcl-tk, I personally wouldn't mind adding xinit as a prereq to gitk and git-gui, since I maintain that package. There's still that annoyance factor that just depending on xinit won't get X running, but at least it will let you download all the bits in one run of setup.exe instead of hitting the FAQ and finding out you have to rerun setup.exe. I don't think I've ever seen it, but does setup.exe support the notion of recommended and/or suggested packages? It seems that the main issue is that xinit is not a hard dependency of these tools/libraries and thus they should not have a hard dependency on xinit defined in the package definition. However, it might make sense to make xinit a recommended dependency that setup.exe could offer to install by default or at least notify the user that they may want to install. I suspect not, but I would like to see such recommended and/or suggested packages. Back when I was using Cygwin gcc so I could learn C, m4 was not installed along with it, and I believe that m4 should at least be shown as a recommended package to go along with gcc. There is no reason to include m4 as a gcc dependency if you are trying to learn C. This would not even be a case of a suggestion. If you needed m4 for some reason (maybe for autoconf/automake) that really would be a case where you need to install m4 separately. You can use gcc quite happily without having m4 installed. For the record, I don't think Yaakov, Corinna, or I are really interested in spending our time adding some sort of suggestion mechanism to setup.exe. This would have ramifications both for setup.exe, for the script which updates setup.ini, and for the genini script. It would likely be a fair amount of work. Given the fact that this has come up repeatedly over the years I am pretty sure that repeated suggestions that setup.exe should be modified to do this are likely not going to have any effect. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Recent upgrade to wish leads to a problem
From: Robert Miles Does it always require xinit, or only sometimes? Sometimes. If only sometimes, why should it always be installed even for computers where there is no need for it? It should be always be installed if the benefits of always installing it outweigh the benefits of not always installing it. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Recent upgrade to wish leads to a problem
From: Christopher Faylor For the record, I don't think Yaakov, Corinna, or I are really interested in spending our time adding some sort of suggestion mechanism to setup.exe. This would have ramifications both for setup.exe, for the script which updates setup.ini, and for the genini script. It would likely be a fair amount of work. I thought I had sometimes seen Setup display a dialog box that said something like The package you have selected requires the following additional packages, with a check box saying Install these packages (RECOMMENDED). What triggers that dialog box to appear? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Recent upgrade to wish leads to a problem
From: Yaakov (Cygwin/X) I haven't seen any questions that I haven't already answered (although it would help if your mail client was capable of preserving a thread). Sorry about that. Hopefully I've cleared up the threading problem now. Please let me know if you are still seeing a problem. The questions I still have are: 1. A. If xinit is added as a package dependency, will Setup notify the user that xinit will also be installed along with the package? B. Will that notification from Setup be enough to give some users a hint that they need to start an X server before using the package? 2. Would adding the xinit dependency spare many users the hassle of having to run Setup twice?
RE: Recent upgrade to wish leads to a problem
From: Achim Gratz [mailto:strom...@nexgo.de] I do and FTR: I don't want the cygwin Xorg server to be a dependency to all programs that might use X because that would pull in a lot of packages that I have no use for on most systems. Right, that would be a disadvantage of making xinit a dependency. My questions are: 1. How many people would need to install xinit? How many people would not need to install xinit? 2. How much of an inconvenience would installing xinit present to people who don't actually need it? 3. Is there some way to make both groups happy? For example, could we have a gitk+xinit package to give people a clue that they might want both (keeping the existing gitk package for people who don't need xinit)? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On 3/2/2012 11:43 AM, Christopher Faylor wrote: On Fri, Mar 02, 2012 at 01:11:49AM -0600, Robert Miles wrote: On 3/1/2012 1:38 PM, Jeremy Bopp wrote: On 03/01/2012 01:05 PM, Eric Blake wrote: On 03/01/2012 10:53 AM, Matt Seitz (matseitz) wrote: [snip] I suspect not, but I would like to see such recommended and/or suggested packages. Back when I was using Cygwin gcc so I could learn C, m4 was not installed along with it, and I believe that m4 should at least be shown as a recommended package to go along with gcc. There is no reason to include m4 as a gcc dependency if you are trying to learn C. This would not even be a case of a suggestion. If you needed m4 for some reason (maybe for autoconf/automake) that really would be a case where you need to install m4 separately. You can use gcc quite happily without having m4 installed. For the record, I don't think Yaakov, Corinna, or I are really interested in spending our time adding some sort of suggestion mechanism to setup.exe. This would have ramifications both for setup.exe, for the script which updates setup.ini, and for the genini script. It would likely be a fair amount of work. Given the fact that this has come up repeatedly over the years I am pretty sure that repeated suggestions that setup.exe should be modified to do this are likely not going to have any effect. The examples I used for learning C all used #include, and therefore required m4 in order to compile. I believe gcc gave an error message in this case showing what was missing, and therefore did not slow down the learning process too much. I remember a second problem with m4 though - some of the #include files in the examples had names starting with blank characters, and m4 did not give an error message that was very useful for identifying this problem and that the Cygwin C libraries were not set up to allow this. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On 3/2/2012 1:02 PM, Matt Seitz (matseitz) wrote: From: Achim Gratz [mailto:strom...@nexgo.de] I do and FTR: I don't want the cygwin Xorg server to be a dependency to all programs that might use X because that would pull in a lot of packages that I have no use for on most systems. Right, that would be a disadvantage of making xinit a dependency. My questions are: 1. How many people would need to install xinit? How many people would not need to install xinit? 2. How much of an inconvenience would installing xinit present to people who don't actually need it? 3. Is there some way to make both groups happy? For example, could we have a gitk+xinit package to give people a clue that they might want both (keeping the existing gitk package for people who don't need xinit)? Would it be adequate to make the installation procedure direct the user to read a text file describing anything that is SOMETIMES needed, and where to find packages to provide it, and where to find similar text files describing any startup procedures needed? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
Yaakov (Cygwin/X) wrote: Using X requires user intervention to start an X server first. No amount of automatic dependencies will change this, and therefore I don't expect that the number of questions would change one iota. You don't think that Setup telling the user package xyz requires package xinit might at least tip off some users that running xyz now requires starting an X server? Even if it doesn't reduce the questions, would it at least reduce the problem of users now having to run Setup a second time to download and install the xinit package? In the case of packages that have both a console mode and an X11 mode, perhaps the package could be split into separate packages, as was done with git, git-gui, and gitk? Can you provide examples of packages for which this isn't already the case? No, I don't have a specific example in mind. I was just trying to anticipate a possible objection of why should we install xinit for a package that is sometimes used with just a text console? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
Christopher Faylor wrote: In the meantime, if people are piling on to suggest this because they think it will cause someone to add xinit as a dependency to something please be assured that this will not happen. OK, what would cause someone to add xinit as a dependency to something? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
Matt Seitz (matseitz) Christopher Faylor wrote: In the meantime, if people are piling on to suggest this because they think it will cause someone to add xinit as a dependency to something please be assured that this will not happen. OK, what would cause someone to add xinit as a dependency to something? One reason I keep asking this question is that I don't understand the rationale against adding xinit. I love that Setup will automatically install the dependencies I need to actually use a package. Setup failing to install a dependency that most users will want seems like a step backwards. So I am trying to understand the rationale behind this position. One of the frustrations I used to have with Linux was repeated cycles of Package A needs package B, install B, Package B needs Package C, install C, Package C needs Package D, etc. I like that modern package managers, like Cygwin Setup or Yum make it much easier by letting me just say I want Package A, and the tool automatically installs all the dependencies for me. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Thu, Mar 01, 2012 at 09:54:23AM -0800, Matt Seitz (matseitz) wrote: Christopher Faylor wrote: In the meantime, if people are piling on to suggest this because they think it will cause someone to add xinit as a dependency to something please be assured that this will not happen. OK, what would cause someone to add xinit as a dependency to something? There is nothing in what I wrote which would suggest that adding xinit as a dependency was a possibility. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Thu, Mar 1, 2012 at 1:14 PM, Christopher Faylor wrote: On Thu, Mar 01, 2012 at 09:54:23AM -0800, Matt Seitz (matseitz) wrote: Christopher Faylor wrote: In the meantime, if people are piling on to suggest this because they think it will cause someone to add xinit as a dependency to something please be assured that this will not happen. OK, what would cause someone to add xinit as a dependency to something? There is nothing in what I wrote which would suggest that adding xinit as a dependency was a possibility. I agree with Matt. If TK is requiring the use of the X server then the X server should be a package dependency of TK. It wasn't a dependency before because the X server wasn't needed but now the X server is needed to use TK. -- Earnie -- https://sites.google.com/site/earnieboyd -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Thu, Mar 01, 2012 at 10:07:33AM -0800, Matt Seitz (matseitz) wrote: Matt Seitz (matseitz) Christopher Faylor wrote: In the meantime, if people are piling on to suggest this because they think it will cause someone to add xinit as a dependency to something please be assured that this will not happen. OK, what would cause someone to add xinit as a dependency to something? One reason I keep asking this question is that I don't understand the rationale against adding xinit. Yaakov posted the rationale. You responded to it. Additional messages insisting how much you want this are really pretty pointless. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Thu, Mar 01, 2012 at 01:20:49PM -0500, Earnie Boyd wrote: On Thu, Mar 1, 2012 at 1:14 PM, Christopher Faylor wrote: On Thu, Mar 01, 2012 at 09:54:23AM -0800, Matt Seitz (matseitz) wrote: Christopher Faylor wrote: In the meantime, if people are piling on to suggest this because they think it will cause someone to add xinit as a dependency to something please be assured that this will not happen. OK, what would cause someone to add xinit as a dependency to something? There is nothing in what I wrote which would suggest that adding xinit as a dependency was a possibility. I agree with Matt. If TK is requiring the use of the X server then the X server should be a package dependency of TK. It wasn't a dependency before because the X server wasn't needed but now the X server is needed to use TK. TK does not require an X server running on the same system. This has been explained in this very thread. If you have points to make, don't make them with a aolme too/aol unless you're planning on addressing the issues that Yaakov raised. Otherwise you're just wasting bandwidth. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Thu, Mar 1, 2012 at 1:21 PM, Christopher Faylor wrote: On Thu, Mar 01, 2012 at 10:07:33AM -0800, Matt Seitz (matseitz) wrote: Matt Seitz (matseitz) Christopher Faylor wrote: In the meantime, if people are piling on to suggest this because they think it will cause someone to add xinit as a dependency to something please be assured that this will not happen. OK, what would cause someone to add xinit as a dependency to something? One reason I keep asking this question is that I don't understand the rationale against adding xinit. Yaakov posted the rationale. You responded to it. Additional messages insisting how much you want this are really pretty pointless. quote Here's my advice: it would be a better use of your time to install xinit and accustom yourself to the wonders of X rather than hopelessly trying to find a way to continue living in the past. /quote quote Using X requires user intervention to start an X server first. No amount of automatic dependencies will change this, and therefore I don't expect that the number of questions would change one iota. /quote But if TK needs an X server started in must be a installed and is a dependency of TK to have X server. Yes, one has to start it but why not require the dependency so that the X server software exists to use already? I agree with Matt, I'm not getting the angst for adding the X server as a dependency for TK which requires it. Having to start it is a different matter. -- Earnie -- https://sites.google.com/site/earnieboyd -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Thu, Mar 1, 2012 at 1:28 PM, Christopher Faylor wrote: TK does not require an X server running on the same system. This has been explained in this very thread. If you have points to make, don't make them with a aolme too/aol unless you're planning on addressing the issues that Yaakov raised. Otherwise you're just wasting bandwidth. And what Windows user who casually installs Cygwin has access to an X server? I sure don't. But I get where you're coming from, it doesn't require the Cygwin/X server it just requires DISPLAY to be set to one that exists somewhere. Still not a good scenario for the unsuspecting idiot. -- Earnie -- https://sites.google.com/site/earnieboyd -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
Christopher Faylor wrote: Yaakov posted the rationale. You responded to it. Additional messages insisting how much you want this are really pretty pointless. Sorry, I don't mean to be a pest. I'll wait and see if Yaakov replies to my latest questions. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
[your mailer doesn't set In-Reply-To correctly, which means you are starting a bunch of new threads instead of replying in-thread] On 03/01/2012 10:53 AM, Matt Seitz (matseitz) wrote: Yaakov (Cygwin/X) wrote: Using X requires user intervention to start an X server first. No amount of automatic dependencies will change this, and therefore I don't expect that the number of questions would change one iota. You don't think that Setup telling the user package xyz requires package xinit might at least tip off some users that running xyz now requires starting an X server? Even if it doesn't reduce the questions, would it at least reduce the problem of users now having to run Setup a second time to download and install the xinit package? While I can't control whether Yaakov adds xinit as a dependency to tcl-tk, I personally wouldn't mind adding xinit as a prereq to gitk and git-gui, since I maintain that package. There's still that annoyance factor that just depending on xinit won't get X running, but at least it will let you download all the bits in one run of setup.exe instead of hitting the FAQ and finding out you have to rerun setup.exe. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Recent upgrade to wish leads to a problem
On 03/01/2012 01:05 PM, Eric Blake wrote: On 03/01/2012 10:53 AM, Matt Seitz (matseitz) wrote: You don't think that Setup telling the user package xyz requires package xinit might at least tip off some users that running xyz now requires starting an X server? Even if it doesn't reduce the questions, would it at least reduce the problem of users now having to run Setup a second time to download and install the xinit package? While I can't control whether Yaakov adds xinit as a dependency to tcl-tk, I personally wouldn't mind adding xinit as a prereq to gitk and git-gui, since I maintain that package. There's still that annoyance factor that just depending on xinit won't get X running, but at least it will let you download all the bits in one run of setup.exe instead of hitting the FAQ and finding out you have to rerun setup.exe. I don't think I've ever seen it, but does setup.exe support the notion of recommended and/or suggested packages? It seems that the main issue is that xinit is not a hard dependency of these tools/libraries and thus they should not have a hard dependency on xinit defined in the package definition. However, it might make sense to make xinit a recommended dependency that setup.exe could offer to install by default or at least notify the user that they may want to install. Less sophisticated users of setup.exe could select to always install all recommended packages by default (this may be the default setting) while more advanced users may disable that option in order to be more choosy. While this wouldn't help the problem of users needing to actually start the X server before using the dependent tools and libraries, it would at least give them a chance to get what they need in a single pass of running setup.exe rather than needing to run it again and try to select the correct additional packages. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On 3/1/2012 8:05 PM, Eric Blake wrote: [your mailer doesn't set In-Reply-To correctly, which means you are starting a bunch of new threads instead of replying in-thread] On 03/01/2012 10:53 AM, Matt Seitz (matseitz) wrote: Yaakov (Cygwin/X) wrote: Using X requires user intervention to start an X server first. No amount of automatic dependencies will change this, and therefore I don't expect that the number of questions would change one iota. You don't think that Setup telling the user package xyz requires package xinit might at least tip off some users that running xyz now requires starting an X server? Even if it doesn't reduce the questions, would it at least reduce the problem of users now having to run Setup a second time to download and install the xinit package? While I can't control whether Yaakov adds xinit as a dependency to tcl-tk, I personally wouldn't mind adding xinit as a prereq to gitk and git-gui, since I maintain that package. There's still that annoyance factor that just depending on xinit won't get X running, but at least it will let you download all the bits in one run of setup.exe instead of hitting the FAQ and finding out you have to rerun setup.exe. Eric, I understand the logic of Yaakov, but I expect that 99.9% of user using git-gui will use the x-server on cygwin. At least the mantainer of clisp-clx had the same thought about its package: sdesc: The new-clx module linkset for clisp ldesc: This is the linkset full+new-clx for X.Org. category: Interpreters requires: clisp xorg-server libXpm4 libXt6 cygwin So your proposal for gittk and git-gui fits in the same view Regards Marco Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
Earnie Boyd ear...@users.sourceforge.net writes: And what Windows user who casually installs Cygwin has access to an X server? I do and FTR: I don't want the cygwin Xorg server to be a dependency to all programs that might use X because that would pull in a lot of packages that I have no use for on most systems. You might recommend companion packages that are typically needed to be combined with a specific selected package when installed in an isolated environment, but please not a dependency. It is perfectly OK to install X applications onto a machine that doesn't have X installed. You don't need a server there, nor do you need an xinit start script or anything else besides the actual application and a handful of DLL. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Thu, 2012-03-01 at 10:42 -0800, Matt Seitz (matseitz) wrote: Christopher Faylor wrote: Yaakov posted the rationale. You responded to it. Additional messages insisting how much you want this are really pretty pointless. Sorry, I don't mean to be a pest. I'll wait and see if Yaakov replies to my latest questions. I haven't seen any questions that I haven't already answered (although it would help if your mail client was capable of preserving a thread). Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Thu, 2012-03-01 at 21:40 +0100, Achim Gratz wrote: Earnie Boyd ear...@users.sourceforge.net writes: And what Windows user who casually installs Cygwin has access to an X server? I do and FTR: I don't want the cygwin Xorg server to be a dependency to all programs that might use X because that would pull in a lot of packages that I have no use for on most systems. You might recommend companion packages that are typically needed to be combined with a specific selected package when installed in an isolated environment, but please not a dependency. It is perfectly OK to install X applications onto a machine that doesn't have X installed. You don't need a server there, nor do you need an xinit start script or anything else besides the actual application and a handful of DLL. Thank you for reinforcing my point. While we certainly promote the Cygwin/X server, forcing xorg-server/xinit as a dependency not only won't prevent questions (since the user still needs to *start* the X server), but those who use other X servers will have this very complaint. Now please excuse me while I get back to orchestrating the next major transition for the distro. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Fri, Mar 2, 2012 at 2:15 AM, Yaakov (Cygwin/X) wrote: Now please excuse me while I get back to orchestrating the next major transition for the distro. Yaakov Thanks very much for this. Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
Yaakov (Cygwin/X) yselkow...@users.sourceforge.net writes: Thank you for reinforcing my point. No, thank you for all your work, because without that we couldn't have this discussion. While we certainly promote the Cygwin/X server, forcing xorg-server/xinit as a dependency not only won't prevent questions (since the user still needs to *start* the X server), but those who use other X servers will have this very complaint. Note: I'm not opposed to give a stronger hint to folks who might not know what an X server is and why they need one. If they don't follow up on that hint it becomes their problem, but you can't reasonably expect someone to look for an answer to a question they don't even have. As long as setup.exe doesn't handle recommendations, how about having an (empty) package X-application (or whatever better name you come up with) that all such applications depend on? I'm still not sure how to get the actual warning to the user, but for starters the postinstall script could fail when it doesn't find the Cygwin X server and leave a file that cygcheck looks for otherwise. If that file is missing I'll get an INCOMPLETE package in cygcheck. If I have an install using an external X server, I can create that file and have clean cygcheck output (and getting the postinstall marked done). Now please excuse me while I get back to orchestrating the next major transition for the distro. Thanks again. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On 3/1/2012 12:07 PM, Matt Seitz (matseitz) wrote: Matt Seitz (matseitz) Christopher Faylor wrote: In the meantime, if people are piling on to suggest this because they think it will cause someone to add xinit as a dependency to something please be assured that this will not happen. OK, what would cause someone to add xinit as a dependency to something? One reason I keep asking this question is that I don't understand the rationale against adding xinit. I love that Setup will automatically install the dependencies I need to actually use a package. Setup failing to install a dependency that most users will want seems like a step backwards. So I am trying to understand the rationale behind this position. One of the frustrations I used to have with Linux was repeated cycles of Package A needs package B, install B, Package B needs Package C, install C, Package C needs Package D, etc. I like that modern package managers, like Cygwin Setup or Yum make it much easier by letting me just say I want Package A, and the tool automatically installs all the dependencies for me. Some questions for which answers might help you understand: Does it always require xinit, or only sometimes? If only sometimes, why should it always be installed even for computers where there is no need for it? Note - I don't have the answers. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On 3/1/2012 1:38 PM, Jeremy Bopp wrote: On 03/01/2012 01:05 PM, Eric Blake wrote: On 03/01/2012 10:53 AM, Matt Seitz (matseitz) wrote: You don't think that Setup telling the user package xyz requires package xinit might at least tip off some users that running xyz now requires starting an X server? Even if it doesn't reduce the questions, would it at least reduce the problem of users now having to run Setup a second time to download and install the xinit package? While I can't control whether Yaakov adds xinit as a dependency to tcl-tk, I personally wouldn't mind adding xinit as a prereq to gitk and git-gui, since I maintain that package. There's still that annoyance factor that just depending on xinit won't get X running, but at least it will let you download all the bits in one run of setup.exe instead of hitting the FAQ and finding out you have to rerun setup.exe. I don't think I've ever seen it, but does setup.exe support the notion of recommended and/or suggested packages? It seems that the main issue is that xinit is not a hard dependency of these tools/libraries and thus they should not have a hard dependency on xinit defined in the package definition. However, it might make sense to make xinit a recommended dependency that setup.exe could offer to install by default or at least notify the user that they may want to install. I suspect not, but I would like to see such recommended and/or suggested packages. Back when I was using Cygwin gcc so I could learn C, m4 was not installed along with it, and I believe that m4 should at least be shown as a recommended package to go along with gcc. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
Previously bin/wish was a link to wish84.exe (from memory). Recently it was upgraded to wish 8.5.exe. Now, unless X is also running, wish fails ... I'm not quite certain which recently upgraded package led to this: tcl-tk or tcltk ..? The tcltk libraries now require a running X server in order to display graphics. This is recent and more importantly intentional according to what I've read on this list ... OK, thanks. I'm really miserable about this advance which has messed badly with my preferred MO (amongst other things, not using X). I tried to revert but got into a tangle (and in fact ended up with no wish* under /bin, at all). I have recovered a non-updated Cygwin from about a month ago (i.e. wish - wish84.exe) which of course offers many opportunities for updating packages using setup.exe. It is not clear to me which update opportunity I should decline in order to keep wish - wish84.exe and not move to wish - wish8.5.exe. Searching for this executable under Search packages yielded Search Results Found 1 matches for wish8.5.exe tcl-tk/tcl-tk-8.5.11-1Tcl X11 toolkit so I de-selected this. However, watching the update process unfold, it is clear that *something else* uninstalled tcl-tk (I saw the phrase Uninstalling tcl-tk). Was it expect? python? both of which were selected in the update process. So as before, I have ended up with no wish* under /bin, at all. (Possibly some dependency is missing in setup.ini? Also there appears to be nothing under [prev] under tcl-tk :o( ) I will try to recover the working version from 1 month ago and start again. Q1 It would be good to know what recent update, separate from tcl-tk explicitly listed above, has led to the un-installation of the existing tcl-tk. Any ideas? Q2 In some other contexts Cygwin provides nox versions additionally to versions requiring a running X server. Is there any chance that tcl-tk-8.4 could be recovered and offered as a nox version? Thank you. Fergus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Wed, 2012-02-29 at 08:24 +, Fergus wrote: OK, thanks. I'm really miserable about this advance which has messed badly with my preferred MO (amongst other things, not using X). The old 8.4 win32 tcl/tk was unmaintained and broken in many ways, as discussed at length on these lists, and now it is gone and isn't coming back. There is no way to keep the 8.4 version because it would conflict with the 8.5 version now used by everything in the distro, and you can't mix-and-match these. Here's my advice: it would be a better use of your time to install xinit and accustom yourself to the wonders of X rather than hopelessly trying to find a way to continue living in the past. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
Fergus writes: Q2 In some other contexts Cygwin provides nox versions additionally to versions requiring a running X server. Is there any chance that tcl-tk-8.4 could be recovered and offered as a nox version? +1 Please! ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Feb 29 09:41, Henry S. Thompson wrote: Fergus writes: Q2 In some other contexts Cygwin provides nox versions additionally to versions requiring a running X server. Is there any chance that tcl-tk-8.4 could be recovered and offered as a nox version? +1 Please! If you manage to do it so that it does in NO way collide with the new release, then there's nothing speaking against it. Just none of the existing maintainers is interested in maintaining it. http://cygwin.com/acronyms/#SHTDI http://cygwin.com/setup.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
Christopher Faylor wrote: The only thing that apparently needs addressing is that you read the list and comprehend what's going on. I wish we could address that by making more people do that. :-) Would it help to add xinit to the requirements for tcl-tk and other packages that now require an X11 server? I know that there are some use cases where xinit isn't actually required. But would the benefit (fewer problem reports from new users) be worth the cost (installing xinit for some users who don't actually require it)? In the case of packages that have both a console mode and an X11 mode, perhaps the package could be split into separate packages, as was done with git, git-gui, and gitk? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Wed, 2012-02-29 at 13:43 -0800, Matt Seitz (matseitz) wrote: Would it help to add xinit to the requirements for tcl-tk and other packages that now require an X11 server? I know that there are some use cases where xinit isn't actually required. But would the benefit (fewer problem reports from new users) be worth the cost (installing xinit for some users who don't actually require it)? Asking the same question in a dozen different ways won't change the answer. Using X requires user intervention to start an X server first. No amount of automatic dependencies will change this, and therefore I don't expect that the number of questions would change one iota. In the case of packages that have both a console mode and an X11 mode, perhaps the package could be split into separate packages, as was done with git, git-gui, and gitk? Can you provide examples of packages for which this isn't already the case? Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Wed, Feb 29, 2012 at 06:57:27PM -0600, Yaakov (Cygwin/X) wrote: On Wed, 2012-02-29 at 13:43 -0800, Matt Seitz (matseitz) wrote: Would it help to add xinit to the requirements for tcl-tk and other packages that now require an X11 server? I know that there are some use cases where xinit isn't actually required. But would the benefit (fewer problem reports from new users) be worth the cost (installing xinit for some users who don't actually require it)? Asking the same question in a dozen different ways won't change the answer. Using X requires user intervention to start an X server first. No amount of automatic dependencies will change this, and therefore I don't expect that the number of questions would change one iota. I agree 100% but this now qualifies as a FAQ so maybe we should add an entry about tcl/tk. In the meantime, if people are piling on to suggest this because they think it will cause someone to add xinit as a dependency to something please be assured that this will not happen. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On 02/24/2012 08:25 AM, Fergus wrote: Previously bin/wish was a link to wish84.exe (from memory). Recently it was upgraded to wish 8.5.exe. Now, unless X is also running, wish fails with $ wish % Application initialization failed: no display name and no $DISPLAY environment variable I'm not quite certain which recently upgraded package led to this: tcl-tk or tcltk or ... Have I identified a real glitch and if so can this problem be addressed? The tcltk libraries now require a running X server in order to display graphics. This is recent and more importantly intentional according to what I've read on this list, so there is nothing to address. :-) -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Recent upgrade to wish leads to a problem
On Fri, Feb 24, 2012 at 09:09:02AM -0600, Jeremy Bopp wrote: On 02/24/2012 08:25 AM, Fergus wrote: Previously bin/wish was a link to wish84.exe (from memory). Recently it was upgraded to wish 8.5.exe. Now, unless X is also running, wish fails with $ wish % Application initialization failed: no display name and no $DISPLAY environment variable I'm not quite certain which recently upgraded package led to this: tcl-tk or tcltk or ... Have I identified a real glitch and if so can this problem be addressed? The tcltk libraries now require a running X server in order to display graphics. This is recent and more importantly intentional according to what I've read on this list, so there is nothing to address. :-) The only thing that apparently needs addressing is that you read the list and comprehend what's going on. I wish we could address that by making more people do that. :-) cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
