Re: Base 64-bit Cygwin now requires Perl?
Warren Young wrote: Name a currently shipping Unixy system that does *not* have Perl installed by default. default seems to me to be the wrong thing to compare to cygwin base. I don't think most cygwin users would be pleased to see cygwin's base install inflated to mimic most distros' defaults, install gigabytes of GNOME/KDE stuff, etc. FreeBSD's base system hasn't included Perl for a decade. Some of the other BSDs may not have it in base either; I'm not sure. Minimalist distros (e.g. TinyCore) and rescue distros (e.g. Parted Magic) routinely leave it out as well. I guess groff needs perl for such things as the chem preprocessor for producing chemical structure diagrams. Not exactly what most people are looking for when they install man. Regular 32-bit cygwin groff doesn't require perl, with the result that typing chem at a command prompt on a base install results in '/usr/bin/env: perl: No such file or directory'. AFAIK nobody ever complained about that. Some distros (e.g. Fedora) have a separate package for the groff stuff that requires perl. Other distros (e.g. Ubuntu) don't split the package but instead have perl as a recommended, rather than required, dependency. I wish there were more of a way cygwin packages could take the latter route. Sometimes it'd be better to let software fail when users try to use obscure functionality that depends on another package they didn't install rather than have the package manager be too smart by half and just install every package their software could ever make use of. -- 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: Installing VIM installs lots of other stuff
Providing the functionality of some obscure, barely used project is not a stated goal for Cygwin. No one here is interested in adapting ourselves to people's expectations for the project if the expectations have nothing to do with the goals of the project. ?? unxutils is just a bundle of win32 binaries of stuff like grep, find, less, patch, make, etc. It's just one representative of many people's attempts to provide basic *nix tools, ranging from every random person out there hosting a win32 build of grep to the MSYS folks. There's nothing 'obscure' or 'barely used' about this goal. It's just a more modest version of the first of Cygwin's 'stated goals.' (Cygwin is a collection of tools which provide a Linux look and feel environment for Windows.) Yes, cygwin is more than that. That would be the 'on steroids' part. People who want more tools and more compatibility than they can get from these simpler bundles of tools are going to need to look at cygwin instead. But those who need everything and the kitchen sink are, honestly, frequently not going to be well-served by cygwin anyways. As I said before, I'm quite aware that there will be plenty of times when the right thing to do for cygwin as a project will be to go ahead and enable some more of a package's optional dependencies. Some users' desire for niche functionality may outweigh other users' desire for a lighter, simpler cygwin install that doesn't need to be updated every day. But the concerns of the latter group of users are not simply irrelevant; there is a tradeoff that needs to be weighed. Also, whenever it's possible to meet both needs by making extra functionality somehow available without the hard dependencies, it's worth considering. Even for the full-fledged distributions this is still a concern. In the present instance, you'll notice that many distributions have a vim-minimal package which depends on libc and little else, and even for the full-fat vim Fedora made an effort not too long ago to remove dependencies on ruby and python (though not perl) - https://bugzilla.redhat.com/show_bug.cgi?id=752785. -- 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: Installing VIM installs lots of other stuff
cgf, I've been using cygwin off and on for ~14 years and I'm aware what it is and is not. Getting defensive and huffy over a rhetorical (not technical/internal) comparison of cygwin to other collections of tools which provide [with varying completeness] a Linux look and feel environment for Windows isn't productive. Nor is making unwarranted assumptions about my ignorance. On my own primary machine I've always had a more complete cygwin install and been glad to be able to, among other things, use the full toolchain to build plenty of software that would not have worked with msys/mingw or whatever. But on my other machines, or for other people, I have frequently installed a fairly minimal cygwin environment. Much of the use these installs have seen would have been adequately met by many of the bundle of win32 binaries offerings which include a shell. Often, however, that wouldn't suffice due to compatibility gotchas or to a missing tool. In such a situation cygwin is doing quite a similar task to what these bundles are intended to do, it's just doing it better and more completely; the internal differences are not particularly relevant to the user. Hence the 'on steroids.' Almost all of the other people I know who use cygwin use it exclusively in this way. Not everybody wants the full build toolchain, every scripting language under the sun, etc. Being more like linux is not a well-defined goal, and it cannot provide any useful guidance in making decisions like this, since for any optional dependency you can find distributions which went either way. Plenty of minimalist distributions out there, and the popularity of different approaches has fluctuated over the years. (Remember when gentoo and USE flags were all the rage?) Being more like the latest Fedora or the like would be well-defined and give concrete guidance, but I can't think of any reason why it would be a reliably good match for your goals for the project or for users' needs. I really appreciate your leadership and all the work you and others have done over the years. I am not here to bicker. You folks have to make tradeoffs and decisions in trying to meet competing goals and disparate users' needs with limited resources, and of course minimalists' concerns won't always win out. Even in this case with vim, where providing for both the minimal and the full-fat is quite possible and is a route taken by many distros, spending effort on that may not be the right use of cygwin resources. I don't pretend to know. But I do think that folks are unnecessarily dismissive of this type of concern. Rick's concern really is relevant, and the decisions and tradeoffs can be made without being dismissive. -- 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: Installing VIM installs lots of other stuff
You'll note, however, that for most distros Perl doesn't depend on openssl, libssp, etc. Also, including extra optional stuff as dependencies is considerably more acceptable when you're installing a primary OS. We expect a Fedora or Arch install to need 10GB and daily security updates. That's the unfortunate reality of linux today. For cygwin, on the other hand, people's expectations are different. A lot of people want cygwin to act like unxutils on steroids and just give them some basic functionality to supplement Windows. Not everybody is trying to make KDE on Cygwin-X their primary desktop. Last year I complained when libcurl suddenly started pulling in the entire kerberos stack (9 packages), presumably due to changing the compile time option to include it. Yaakov dismissed my complaint as irrelevant because disk space is cheap. I didn't feel like arguing the point then, but the only thing I think of when I hear kerberos is the many many high-publicity vulnerabilities in the kerberos stack over the years. If you're putting cygwin on a bunch of machines just to ensure they all have access to a few basic utilities, keeping update worries to a minimum would be nice. I know that for a lot of packages the packagers will have legitimate reasons to decide that some users' desire for increased functionality overrides other users' desires for a small, possibly even portable, cygwin install with minimal update needs. Such is life. But please don't just completely dismiss the latter group of users' concerns as irrelevant. -- 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: [ANNOUNCEMENT] Updated: curl-7.24.0-3
This update pulls in no fewer than nine Kerberos support packages, and since all kinds of things rely on libcurl, these packages effectively become part of a cygwin base installation. Is there some way this could be avoided? Maybe a separate libcurl-kerberos package or 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: cyggfortran-3.dll broken ?
Since Dave Korn was wondering how many people this would be bothering, I'm just chiming in to say I was bitten by this too (since I both run cygwin setup less often than others and use octave less often than others, and since I'm not subscribed to the list, I'm late to the party). It was kind of baffling to have no output, error message, core dump, etc- just an immediate return regardless of what command line options I specified- and to have cygcheck say all was well with the library situation. Thankfully the thread Octave 3.4.0 crashes silently on the latest cygwin 1.7.8 over on the Octave mailing list came up high in search results and led to this thread. For me, just rolling back libgfortran is fine, and though I think it's kind of rough to have such API breakage in a upgrade which doesn't change the version number at all (just the build number), I'd certainly prefer that limited development resources be spent on getting gcc 4.6 and associated binutils etc ready for prime time. -- 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
GCC on 64-bit windows
I'm running Windows 7 64-bit, and I installed Cygwin 1.7 hoping to use the build toolchain from SciTE and Eclipse. My cygwin installation works, and I can run gcc just fine from a cygwin shell. Eclipse works just fine (though the debugger interface sends complaints to console about missing dlls etc at program start, it doesn't seem to cause trouble). However, trying to launch gcc from Windows (cmd.exe, the run dialog, etc) or from SciTE (as the build command) gives one or the other of the following two error messages: This version of %1 is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher. Unsupported 16-bit Application The program or feature \??\c:\cygwin\bin\g++.exe cannot start or run due to incompatibility with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available. I've tested most all of the binaries in c:\cygwin\bin and outside of the gcc ones all of them, including the rest of the build toolchain, seem to be launchable from windows. Anyone know why gcc would be different? -- 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
patchutils 0.2.30-1
Is there any particular reason why patchutils 0.2.30-1 is marked as experimental? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
