Re: [HEADSUP] Base category
On Dec 10 16:34, Warren Young wrote: On Dec 10, 2014, at 4:05 AM, Corinna Vinschen wrote: Isn't that the same for all distros? Cygwin has just a few thousand packages, Linux distros have 10s of thousands. I just re-did the count, and I get 4,453 for the Cygwin official repo (x86) plus another 6,556 in Ports. My point, though, is that I’m surprised Cygwin is even in this space. Back when I started with Cygwin, it was little more than a POSIX.1 userland. [...] Of course I don’t need to understand it. It’s someone’s itch, and it pleases them to help Cygwin out by scratching it. To me it's also neat as proof of concept. I'm constantly amazed that all this stuff really works on Cygwin. Oh well. I'm running Windows in VMs only for years and I still didn't disappear from the project :} It’s a bit different for you, isn’t it? For you, it’s a key part of your employment. For me, it’s been a means to an end, while I waited for the computing world to change enough that I could get off Windows. Well, if Cygwin pointed you in the right direction, it also served its purpose :) I'm sorry to read that. In fact I had hoped you would be willing to look a bit more into the documentation again, after you so kindly pulled it into the 21st century last year. There's certainly still much room for improvement. I kind of thought I’d been kicked off that project, after leaving the autodep stuff hanging. :) I'd never have kicked you out. Contrary to that, I was disappointed that you apparently quickly lost interested in working on the docs. Point me at a problem area. If it annoys me enough, I will be motivated to fix it. Well, that's kind of the problem, isn't it? If you don't build Cygwin, you don't have a motivation to fix anything in the build process. And the other side of the coin: Documentation is a necessary evil to me. As long as it builds I don't even realize something is missing. But see below. As for your new nsswitch type docs, the first pass still needs to be done by you, or whoever knows what’s going on. But, I can still make a cleanup pass on it. That would be cool. Apart from generic cleanup, I'm really having a problem which results in a somewhat confused layout. The problem is, I'm struggling with lists. Itemized lists, var lists, you name it. Sometimes I'm using screen instead of lists just to make sure I get what I want. For instance, the Well-known SID connection: Let's discuss the SID=uid/gid mapping first. Here's how it works. Well-known SIDs in the NT_AUTHORITY domain of the S-1-5-RID type, or aliases of the S-1-5-32-RID type are mapped to the uid/gid value RID. Examples: screen SYSTEM S-1-5-18= uid/gid: 18 Users S-1-5-32-545= uid/gid: 545 /screen [...etc...] You see what I'm trying to say, but there's certainly a better way to get a neat layout for this, with the equivalence signs neatly in the same columns... And neither the layout of varlists, nor the layout of segmentedlists is what I'm looking for. Right now, in varlists the right column starts in the line below the left column, rather than just on the right of the same line, and in segmented lists the columns are cnetered to each other if they wrap around, which also doesn't look right. I would like to have a simple list type, which allos multiple columns, with the columns being left-adjusted as well as vertically always start in the same line. Like this: Column1Column2 aaabbb ccc but neither varlists nor segmentedlists seem to do it as they should. You won't believe how much time I already spent just trying to get the layout right... Halp? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp81Pw1W8S75.pgp Description: PGP signature
Re: [HEADSUP] Base category
On Dec 9 23:19, Marco Atzeri wrote: On 12/9/2014 10:46 PM, Ken Brown wrote: On 12/9/2014 2:52 PM, Corinna Vinschen wrote: On Dec 9 14:10, Ken Brown wrote: On 12/9/2014 12:48 PM, Corinna Vinschen wrote: Come to think of it. When exactly do we want to allow installing packages without also installing the deps? How much sense does this option really have? I've had occasion to do this when testing/debugging. And I can imagine experienced users who correctly know that they can safely ignore some dependencies. So I wouldn't want it to be impossible. But maybe we can arrange it so that dependencies are installed by default, without a dialog, unless the user has explicitly requested the contrary. For example, there could be a checkbox on an early screen saying something like, For each selected package, install all of its dependencies (RECOMMENDED). The box would of course be checked by default. Apart from the Base packages thingy which was my reason to start this thread, the dialog as such isn't bad. It's pretty much the same thing as on Fedora (let's say, KDE's Apper), even more detailed. What about just not showing the Select required packages (RECOMMEND) check-box, unless you use a certain command line option? That sounds good. Maybe --show-deps? That sounds a bit ambiguous. It's about the choice to not install deps, not about showing deps at all. Ken To me sounds wrong the concept, why we should hide this check to the users ? I have seen recently too many wrong dependencies pullings extra unnecessary packages. I prefer to have users that could note the issue and complain instead of installing everything but the kitchen sink behind their back. Did you (and Ken) get me wrong, by any chance? What I was trying to say is *not* to remove the dependency dialog. What I was trying to say is *only* to remove the check box in that dialog, which allows to install the selected packages without their dependencies. Just this check box. Such a check-box, or its equivalent on the command line, doesn't exist in other installers either. Giving the choice to install without the dependencies is in 99% of the cases wrong. If you install package A on Fedora, the installer will tell you it has to install packages B, C, and D, to fullfill the dependencies for A. The choice you have is to install A, B, C and D, or nothing at all. There's no choice to install package A alone, which is what this check box allows. Again, the dialog itself is fine. The choice to install without the deps usually is not. *Iff* it's fine, then only for users who know what they are doing. As for the dialog itself, I just think it would make sense to fullfil deps of Base packages automatically. If the user chooses to install other packages outside Base, and these packages have additional deps, then *of course* the additional deps should show up in that dialog. Does that clarify what I mean? I'm sorry if my original mail was unclear. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpPXd3gUnePG.pgp Description: PGP signature
Re: [HEADSUP] Base category
On 12/10/2014 10:54 AM, Corinna Vinschen wrote: On Dec 9 23:19, Marco Atzeri wrote: To me sounds wrong the concept, why we should hide this check to the users ? I have seen recently too many wrong dependencies pullings extra unnecessary packages. I prefer to have users that could note the issue and complain instead of installing everything but the kitchen sink behind their back. Did you (and Ken) get me wrong, by any chance? What I was trying to say is *not* to remove the dependency dialog. What I was trying to say is *only* to remove the check box in that dialog, which allows to install the selected packages without their dependencies. Just this check box. Such a check-box, or its equivalent on the command line, doesn't exist in other installers either. Giving the choice to install without the dependencies is in 99% of the cases wrong. If you install package A on Fedora, the installer will tell you it has to install packages B, C, and D, to fullfill the dependencies for A. The choice you have is to install A, B, C and D, or nothing at all. There's no choice to install package A alone, which is what this check box allows. Again, the dialog itself is fine. The choice to install without the deps usually is not. *Iff* it's fine, then only for users who know what they are doing. As for the dialog itself, I just think it would make sense to fullfil deps of Base packages automatically. If the user chooses to install other packages outside Base, and these packages have additional deps, then *of course* the additional deps should show up in that dialog. Does that clarify what I mean? I'm sorry if my original mail was unclear. Hi Corinna, It is/was clear, but I still disagree. I do not see the advantage of such reduced or hidden option. I used a lot of time the check box to avoid pulling unwanted/questionable dependencies (eg gcc-java pulling python3..). Last time I used RPM, it still allowed to force install ignoring dependency. Corinna Marco
Re: [HEADSUP] Base category
On Dec 10 11:29, Marco Atzeri wrote: On 12/10/2014 10:54 AM, Corinna Vinschen wrote: On Dec 9 23:19, Marco Atzeri wrote: To me sounds wrong the concept, why we should hide this check to the users ? I have seen recently too many wrong dependencies pullings extra unnecessary packages. I prefer to have users that could note the issue and complain instead of installing everything but the kitchen sink behind their back. Did you (and Ken) get me wrong, by any chance? What I was trying to say is *not* to remove the dependency dialog. What I was trying to say is *only* to remove the check box in that dialog, which allows to install the selected packages without their dependencies. Just this check box. Such a check-box, or its equivalent on the command line, doesn't exist in other installers either. Giving the choice to install without the dependencies is in 99% of the cases wrong. If you install package A on Fedora, the installer will tell you it has to install packages B, C, and D, to fullfill the dependencies for A. The choice you have is to install A, B, C and D, or nothing at all. There's no choice to install package A alone, which is what this check box allows. Again, the dialog itself is fine. The choice to install without the deps usually is not. *Iff* it's fine, then only for users who know what they are doing. As for the dialog itself, I just think it would make sense to fullfil deps of Base packages automatically. If the user chooses to install other packages outside Base, and these packages have additional deps, then *of course* the additional deps should show up in that dialog. Does that clarify what I mean? I'm sorry if my original mail was unclear. Hi Corinna, It is/was clear, but I still disagree. I do not see the advantage of such reduced or hidden option. Hidden to the normal user for which ignoring deps would typically result in a broken installation. Visible to the knowledgable user. I used a lot of time the check box to avoid pulling unwanted/questionable dependencies (eg gcc-java pulling python3..). Wouldn't it be better instead to discuss and then remove these questionable deps as soon as you notice them? Last time I used RPM, it still allowed to force install ignoring dependency. I was more talking about yum or KDE's Apper. To ignore deps in RPM you have to know and use the --nodeps option as well. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpTyoVeXKbhk.pgp Description: PGP signature
Re: [HEADSUP] Base category
On Dec 9 16:04, Warren Young wrote: On Dec 9, 2014, at 3:48 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Dec 8 15:28, Warren Young wrote: I’ve got in mind the 2-3 times in my memory where Perl has crept into the minimal install set via some indirect dependency. I still don't grok why everybody is so hot on keeping the base install so very small. Our Base package set is really tiny in comparison with any Linux distro. Perl is default on most of them. Why not for us? Disk space is dirt cheap these days. I agree with both sides of the argument. A tightly-scoped minimal install is a good thing, and it would be a good thing if we could have a universally-available programming language that fills the vast gap between sh and C. [1] There is? :) It boggles my mind how much is in the Cygwin package repository, and then how much more is in Ports. To some extent, this has to be a reflection of Sturgeon’s Law. [2] Isn't that the same for all distros? Cygwin has just a few thousand packages, Linux distros have 10s of thousands. It is possible to install so much within Cygwin that you turn Windows into a rather slow Linux distro with a demented kernel. If you’re going to do that, why not just switch to Linux or OS X on the desktop, and run *Windows* in a VM? This is as good a time as any to tell anyone who cares that I’ve finally done just that: I recently retired my last machine that boots natively into Windows. I only have VMs now. I’ll probably be fading from the Cygwin scene as a consequence. I expect it to be a slow fade, since I still feel the need to pay back some of the value Cygwin provided to me in the years before we got mature VM systems. Oh well. I'm running Windows in VMs only for years and I still didn't disappear from the project :} Therefore: So long, and can I help you find some fish before I go? :) I'm sorry to read that. In fact I had hoped you would be willing to look a bit more into the documentation again, after you so kindly pulled it into the 21st century last year. There's certainly still much room for improvement. Thanks for your long-time involvment with Cygwin and bearing with us all the time. Please stick to us as long as you like. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgplLKBtpX9Km.pgp Description: PGP signature
Re: [HEADSUP] Base category
On 2014-12-10 10:54, Corinna Vinschen wrote: Did you (and Ken) get me wrong, by any chance? What I was trying to say is *not* to remove the dependency dialog. What I was trying to say is *only* to remove the check box in that dialog, which allows to install the selected packages without their dependencies. Just this check box. Such a check-box, or its equivalent on the command line, doesn't exist in other installers either. Giving the choice to install without the dependencies is in 99% of the cases wrong. If you install package A on Fedora, the installer will tell you it has to install packages B, C, and D, to fullfill the dependencies for A. The choice you have is to install A, B, C and D, or nothing at all. There's no choice to install package A alone, which is what this check box allows. Again, the dialog itself is fine. The choice to install without the deps usually is not. *Iff* it's fine, then only for users who know what they are doing. As for the dialog itself, I just think it would make sense to fullfil deps of Base packages automatically. If the user chooses to install other packages outside Base, and these packages have additional deps, then *of course* the additional deps should show up in that dialog. Does that clarify what I mean? I'm sorry if my original mail was unclear. From time to time, I have a lot of Cygwin processes that I do not feel like terminating, but I still would like to install or update one specific Cygwin tool. I use Keep in the setup gui for this, and then pick the specific thing I need (which usually do not interfere with anything else). However, with the setup dependency tracker not differentiating between last/prev dependencies (and I dare not even think of deps of old packages which are no longer available in setup) this action usually brings up a hefty list of false dependencies. I would like to still be able to pick a single new package and leave the rest as is, and I would like to NOT be required to download the latest setup and run it using some newfangled command line option for this. It is very nice to be able run the lastest setup with a few clicks on the web-site. $.02 Cheers, Peter
Re: [HEADSUP] Base category
On Dec 10 12:48, Peter Rosin wrote: On 2014-12-10 10:54, Corinna Vinschen wrote: Did you (and Ken) get me wrong, by any chance? What I was trying to say is *not* to remove the dependency dialog. What I was trying to say is *only* to remove the check box in that dialog, which allows to install the selected packages without their dependencies. Just this check box. Such a check-box, or its equivalent on the command line, doesn't exist in other installers either. Giving the choice to install without the dependencies is in 99% of the cases wrong. If you install package A on Fedora, the installer will tell you it has to install packages B, C, and D, to fullfill the dependencies for A. The choice you have is to install A, B, C and D, or nothing at all. There's no choice to install package A alone, which is what this check box allows. Again, the dialog itself is fine. The choice to install without the deps usually is not. *Iff* it's fine, then only for users who know what they are doing. As for the dialog itself, I just think it would make sense to fullfil deps of Base packages automatically. If the user chooses to install other packages outside Base, and these packages have additional deps, then *of course* the additional deps should show up in that dialog. Does that clarify what I mean? I'm sorry if my original mail was unclear. From time to time, I have a lot of Cygwin processes that I do not feel like terminating, but I still would like to install or update one specific Cygwin tool. I use Keep in the setup gui for this, and then pick the specific thing I need (which usually do not interfere with anything else). However, with the setup dependency tracker not differentiating between last/prev dependencies (and I dare not even think of deps of old packages which are no longer available in setup) this action usually brings up a hefty list of false dependencies. I would like to still be able to pick a single new package and leave the rest as is, and I would like to NOT be required to download the latest setup and run it using some newfangled command line option for this. It is very nice to be able run the lastest setup with a few clicks on the web-site. Sigh. Suggestion retracted. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp2Z3jQkDQXJ.pgp Description: PGP signature
Re: [HEADSUP] Base category
Peter Rosin writes: I would like to still be able to pick a single new package and leave the rest as is, and I would like to NOT be required to download the latest setup and run it using some newfangled command line option for this. It is very nice to be able run the lastest setup with a few clicks on the web-site. tar -C / -xvf /path/to/package | gzip -9c /etc/setup/package.lst.gz egrep ^package /etc/setup/installed.db || echo package package-0-0.tar.bz2 0 /etc/setup/installed.db 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
Re: [HEADSUP] Base category
On 2014-12-10 22:27, Achim Gratz wrote: Peter Rosin writes: I would like to still be able to pick a single new package and leave the rest as is, and I would like to NOT be required to download the latest setup and run it using some newfangled command line option for this. It is very nice to be able run the lastest setup with a few clicks on the web-site. tar -C / -xvf /path/to/package | gzip -9c /etc/setup/package.lst.gz egrep ^package /etc/setup/installed.db || echo package package-0-0.tar.bz2 0 /etc/setup/installed.db Yes, nothing can go wrong if I do that. And I will never forget to rebase. And I will never forget to trigger info-generation. It's just perfect. In fact, I will not get any nasty surprises ever if I do it like that and I can just get rid of setup entirely. Whatever do I need it for anyway? Cheers, Peter
Re: [HEADSUP] Base category
On Dec 10, 2014, at 4:05 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: It boggles my mind how much is in the Cygwin package repository, and then how much more is in Ports. To some extent, this has to be a reflection of Sturgeon’s Law. [2] Isn't that the same for all distros? Cygwin has just a few thousand packages, Linux distros have 10s of thousands. I just re-did the count, and I get 4,453 for the Cygwin official repo (x86) plus another 6,556 in Ports. My point, though, is that I’m surprised Cygwin is even in this space. Back when I started with Cygwin, it was little more than a POSIX.1 userland. I understand “nonstandard” additions like ssh, rsync, a basic X server, lots of libraries, and lots of development tools. What I don’t understand is WindowMaker, KDE, music notation software, etc. It seems to me that a lot of this is best left to Windows proper, or native apps for it. Of course I don’t need to understand it. It’s someone’s itch, and it pleases them to help Cygwin out by scratching it. I only have VMs now. I’ll probably be fading from the Cygwin scene as a consequence. Oh well. I'm running Windows in VMs only for years and I still didn't disappear from the project :} It’s a bit different for you, isn’t it? For you, it’s a key part of your employment. For me, it’s been a means to an end, while I waited for the computing world to change enough that I could get off Windows. It’s not that I don’t want to continue helping with Cygwin, but that it’s no longer a thing I use often. I'm sorry to read that. In fact I had hoped you would be willing to look a bit more into the documentation again, after you so kindly pulled it into the 21st century last year. There's certainly still much room for improvement. I kind of thought I’d been kicked off that project, after leaving the autodep stuff hanging. :) Point me at a problem area. If it annoys me enough, I will be motivated to fix it. As for your new nsswitch type docs, the first pass still needs to be done by you, or whoever knows what’s going on. But, I can still make a cleanup pass on it.
Re: [HEADSUP] Base category
On Dec 8 15:28, Warren Young wrote: On Dec 6, 2014, at 9:57 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Also, can we automate this? If you’re suggesting an automatic promotion of package to Base, I’d argue for the opposite: automatic detection of dependency creep. I’ve got in mind the 2-3 times in my memory where Perl has crept into the minimal install set via some indirect dependency. When this sort of thing happens, it should cause a red flag somewhere, so that the dependency creep can be pruned back again. I still don't grok why everybody is so hot on keeping the base install so very small. Our Base package set is really tiny in comparison with any Linux distro. Perl is default on most of them. Why not for us? Disk space is dirt cheap these days. One way to do this is to take a look at all the packages currently in a minimal install, decide if they really should be in that set, and add them to Base. Then, on each re-generation of setup.ini, run the dependency resolution algorithm on the package tree and see if there are any packages not in Base that would have to be installed to satisfy the algorithm. The dependency resolution algorithm is in setup, not in upset, and it doesn't belong there. setup.ini is regenerated every time a package is updated. Who's going to do the manual inspection of the results every time? My concern is the useless do you really want to install the following dependencies? dialog. It just doesn't make sense for the deps of the Base category. Finding a neat solution which avoids this dialog would be nice to have. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpzH7Tt1WsB4.pgp Description: PGP signature
Re: [HEADSUP] Base category
Corinna Vinschen writes: I still don't grok why everybody is so hot on keeping the base install so very small. Our Base package set is really tiny in comparison with any Linux distro. Perl is default on most of them. Why not for us? Disk space is dirt cheap these days. It's more like the additional complexity and growing attack surface of an install with tools you don't regularly use. This discussion was (and still is) going on for Linux just as well, only that the more features is better camp has won. The dependency resolution algorithm is in setup, not in upset, and it doesn't belong there. setup.ini is regenerated every time a package is updated. Who's going to do the manual inspection of the results every time? Only the leaf packages that are defined to be in Base should be in that group, IMHO. The set of dependencies is going to change regardless, so trying to chase them is pointless. My concern is the useless do you really want to install the following dependencies? dialog. It just doesn't make sense for the deps of the Base category. Finding a neat solution which avoids this dialog would be nice to have. As I said, setup.exe could treat dependencies of a Base package as explicitly requested for install, just as it does for Base itself. For direct dependencies this isn't hard, following dependency chains this way might require one more pass (unless we inject Base into the dependencies we encounter). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [HEADSUP] Base category
On Dec 9 17:35, Achim Gratz wrote: Corinna Vinschen writes: I still don't grok why everybody is so hot on keeping the base install so very small. Our Base package set is really tiny in comparison with any Linux distro. Perl is default on most of them. Why not for us? Disk space is dirt cheap these days. It's more like the additional complexity and growing attack surface of an install with tools you don't regularly use. This discussion was (and still is) going on for Linux just as well, only that the more features is better camp has won. I'm in the latter camp, too :) The dependency resolution algorithm is in setup, not in upset, and it doesn't belong there. setup.ini is regenerated every time a package is updated. Who's going to do the manual inspection of the results every time? Only the leaf packages that are defined to be in Base should be in that group, IMHO. The set of dependencies is going to change regardless, so trying to chase them is pointless. I see the point. My concern is the useless do you really want to install the following dependencies? dialog. It just doesn't make sense for the deps of the Base category. Finding a neat solution which avoids this dialog would be nice to have. As I said, setup.exe could treat dependencies of a Base package as explicitly requested for install, just as it does for Base itself. For direct dependencies this isn't hard, following dependency chains this way might require one more pass (unless we inject Base into the dependencies we encounter). Right. I was only pointing out what I was up to. Setup definitely needs another tweak to support that. Come to think of it. When exactly do we want to allow installing packages without also installing the deps? How much sense does this option really have? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpDC186OoKEx.pgp Description: PGP signature
Re: [HEADSUP] Base category
On 12/9/2014 12:48 PM, Corinna Vinschen wrote: On Dec 9 17:35, Achim Gratz wrote: Corinna Vinschen writes: I still don't grok why everybody is so hot on keeping the base install so very small. Our Base package set is really tiny in comparison with any Linux distro. Perl is default on most of them. Why not for us? Disk space is dirt cheap these days. It's more like the additional complexity and growing attack surface of an install with tools you don't regularly use. This discussion was (and still is) going on for Linux just as well, only that the more features is better camp has won. I'm in the latter camp, too :) The dependency resolution algorithm is in setup, not in upset, and it doesn't belong there. setup.ini is regenerated every time a package is updated. Who's going to do the manual inspection of the results every time? Only the leaf packages that are defined to be in Base should be in that group, IMHO. The set of dependencies is going to change regardless, so trying to chase them is pointless. I see the point. My concern is the useless do you really want to install the following dependencies? dialog. It just doesn't make sense for the deps of the Base category. Finding a neat solution which avoids this dialog would be nice to have. As I said, setup.exe could treat dependencies of a Base package as explicitly requested for install, just as it does for Base itself. For direct dependencies this isn't hard, following dependency chains this way might require one more pass (unless we inject Base into the dependencies we encounter). Right. I was only pointing out what I was up to. Setup definitely needs another tweak to support that. Come to think of it. When exactly do we want to allow installing packages without also installing the deps? How much sense does this option really have? I've had occasion to do this when testing/debugging. And I can imagine experienced users who correctly know that they can safely ignore some dependencies. So I wouldn't want it to be impossible. But maybe we can arrange it so that dependencies are installed by default, without a dialog, unless the user has explicitly requested the contrary. For example, there could be a checkbox on an early screen saying something like, For each selected package, install all of its dependencies (RECOMMENDED). The box would of course be checked by default. Ken
Re: [HEADSUP] Base category
On Dec 9 14:10, Ken Brown wrote: On 12/9/2014 12:48 PM, Corinna Vinschen wrote: Come to think of it. When exactly do we want to allow installing packages without also installing the deps? How much sense does this option really have? I've had occasion to do this when testing/debugging. And I can imagine experienced users who correctly know that they can safely ignore some dependencies. So I wouldn't want it to be impossible. But maybe we can arrange it so that dependencies are installed by default, without a dialog, unless the user has explicitly requested the contrary. For example, there could be a checkbox on an early screen saying something like, For each selected package, install all of its dependencies (RECOMMENDED). The box would of course be checked by default. Apart from the Base packages thingy which was my reason to start this thread, the dialog as such isn't bad. It's pretty much the same thing as on Fedora (let's say, KDE's Apper), even more detailed. What about just not showing the Select required packages (RECOMMEND) check-box, unless you use a certain command line option? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpdmQpy8xwD5.pgp Description: PGP signature
Re: [HEADSUP] Base category
On 12/9/2014 2:52 PM, Corinna Vinschen wrote: On Dec 9 14:10, Ken Brown wrote: On 12/9/2014 12:48 PM, Corinna Vinschen wrote: Come to think of it. When exactly do we want to allow installing packages without also installing the deps? How much sense does this option really have? I've had occasion to do this when testing/debugging. And I can imagine experienced users who correctly know that they can safely ignore some dependencies. So I wouldn't want it to be impossible. But maybe we can arrange it so that dependencies are installed by default, without a dialog, unless the user has explicitly requested the contrary. For example, there could be a checkbox on an early screen saying something like, For each selected package, install all of its dependencies (RECOMMENDED). The box would of course be checked by default. Apart from the Base packages thingy which was my reason to start this thread, the dialog as such isn't bad. It's pretty much the same thing as on Fedora (let's say, KDE's Apper), even more detailed. What about just not showing the Select required packages (RECOMMEND) check-box, unless you use a certain command line option? That sounds good. Maybe --show-deps? Ken
Re: [HEADSUP] Base category
On 12/9/2014 10:46 PM, Ken Brown wrote: On 12/9/2014 2:52 PM, Corinna Vinschen wrote: On Dec 9 14:10, Ken Brown wrote: On 12/9/2014 12:48 PM, Corinna Vinschen wrote: Come to think of it. When exactly do we want to allow installing packages without also installing the deps? How much sense does this option really have? I've had occasion to do this when testing/debugging. And I can imagine experienced users who correctly know that they can safely ignore some dependencies. So I wouldn't want it to be impossible. But maybe we can arrange it so that dependencies are installed by default, without a dialog, unless the user has explicitly requested the contrary. For example, there could be a checkbox on an early screen saying something like, For each selected package, install all of its dependencies (RECOMMENDED). The box would of course be checked by default. Apart from the Base packages thingy which was my reason to start this thread, the dialog as such isn't bad. It's pretty much the same thing as on Fedora (let's say, KDE's Apper), even more detailed. What about just not showing the Select required packages (RECOMMEND) check-box, unless you use a certain command line option? That sounds good. Maybe --show-deps? Ken To me sounds wrong the concept, why we should hide this check to the users ? I have seen recently too many wrong dependencies pullings extra unnecessary packages. I prefer to have users that could note the issue and complain instead of installing everything but the kitchen sink behind their back. Marco
Re: [HEADSUP] Base category
On Dec 9, 2014, at 3:48 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Dec 8 15:28, Warren Young wrote: I’ve got in mind the 2-3 times in my memory where Perl has crept into the minimal install set via some indirect dependency. I still don't grok why everybody is so hot on keeping the base install so very small. Our Base package set is really tiny in comparison with any Linux distro. Perl is default on most of them. Why not for us? Disk space is dirt cheap these days. I agree with both sides of the argument. A tightly-scoped minimal install is a good thing, and it would be a good thing if we could have a universally-available programming language that fills the vast gap between sh and C. [1] While I lean toward your side, that’s only because I’ve been a Perl programmer for about 2 decades. If I look at it impartially, I can’t say that Perl really should get a special place short of being formally included in POSIX or similar. Otherwise, why not include Python, Ruby, Lua, Scheme…? It can't just be because it’s older; Scheme’s got Perl beat by a dozen years. It’s older than Awk! I think in the end, I look at Cygwin as more similar to a minimal server-focussed *ix than to a desktop *ix. I believe this difference stems from the fact that Windows is a pretty capable desktop environment in its own right. Obviously far from ideal, but I think most of those of us who use Cygwin are more interested in filling in gaps in Windows than in replacing it. It boggles my mind how much is in the Cygwin package repository, and then how much more is in Ports. To some extent, this has to be a reflection of Sturgeon’s Law. [2] It is possible to install so much within Cygwin that you turn Windows into a rather slow Linux distro with a demented kernel. If you’re going to do that, why not just switch to Linux or OS X on the desktop, and run *Windows* in a VM? This is as good a time as any to tell anyone who cares that I’ve finally done just that: I recently retired my last machine that boots natively into Windows. I only have VMs now. I’ll probably be fading from the Cygwin scene as a consequence. I expect it to be a slow fade, since I still feel the need to pay back some of the value Cygwin provided to me in the years before we got mature VM systems. Therefore: So long, and can I help you find some fish before I go? :) [1] This is what sparked my post to the -talk list, if it’s not clear by now. [2] 90% of everything is crap, but we disagree on which 90% that is.
[HEADSUP] Base category
Hi, isn't it rather annoying that even Base packages have dependencies outside the Base category? So, even if I perform a plain Base-only installation, I get asked if dependencies shall be fullfilled, which, as a question, is more than borderline anyway. Therefore, shouldn't we put all packages Base packages depend on into Base as well? Also, can we automate this? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpITJsYmLibt.pgp Description: PGP signature
Re: [HEADSUP] Base category
On 12/6/2014 11:57 AM, Corinna Vinschen wrote: Hi, isn't it rather annoying that even Base packages have dependencies outside the Base category? So, even if I perform a plain Base-only installation, I get asked if dependencies shall be fullfilled, which, as a question, is more than borderline anyway. Therefore, shouldn't we put all packages Base packages depend on into Base as well? That makes sense to me. The popup about dependencies could be confusing for someone installing Cygwin for the first time. Also, can we automate this? I'm not sure that's a good idea. If the dependencies of a Base package change, it's probably good for this to be noticeable, in case it was due to a packaging error. Ken
Re: [HEADSUP] Base category
On Dec 6 12:40, Ken Brown wrote: On 12/6/2014 11:57 AM, Corinna Vinschen wrote: Hi, isn't it rather annoying that even Base packages have dependencies outside the Base category? So, even if I perform a plain Base-only installation, I get asked if dependencies shall be fullfilled, which, as a question, is more than borderline anyway. Therefore, shouldn't we put all packages Base packages depend on into Base as well? That makes sense to me. The popup about dependencies could be confusing for someone installing Cygwin for the first time. ACK. Also, can we automate this? I'm not sure that's a good idea. If the dependencies of a Base package change, it's probably good for this to be noticeable, in case it was due to a packaging error. Uh, I was only talking about automating to add the categories to all affected packages once and get a list of packages to send to this list. Sorry if that wasn't clear :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpljSzr1hJ1k.pgp Description: PGP signature
Re: [HEADSUP] Base category
On 12/6/2014 12:57 PM, Corinna Vinschen wrote: On Dec 6 12:40, Ken Brown wrote: On 12/6/2014 11:57 AM, Corinna Vinschen wrote: Hi, isn't it rather annoying that even Base packages have dependencies outside the Base category? So, even if I perform a plain Base-only installation, I get asked if dependencies shall be fullfilled, which, as a question, is more than borderline anyway. Therefore, shouldn't we put all packages Base packages depend on into Base as well? That makes sense to me. The popup about dependencies could be confusing for someone installing Cygwin for the first time. ACK. Also, can we automate this? I'm not sure that's a good idea. If the dependencies of a Base package change, it's probably good for this to be noticeable, in case it was due to a packaging error. Uh, I was only talking about automating to add the categories to all affected packages once and get a list of packages to send to this list. I just did a test install on each architecture and extracted the info from setup.log. Both arches: _autorebase _update-info-dir bzip2 ca-certificates groff less libargp libattr1 libblkid1 libbz2_1 libffi6 libgcc1 libgdbm4 libgmp10 libiconv libiconv2 libintl8 liblzma5 libmpfr4 libncursesw10 libopenssl100 libp11-kit0 libpcre1 libpipeline1 libpopt0 libsmartcols1 libstdc++6 libtasn1_6 libuuid1 lynx p11-kit p11-kit-trust popt xz zlib0 32-bit only: libcharset1 libncurses10 64-bit only: libreadline7 Ken
Re: [HEADSUP] Base category
isn't it rather annoying that even Base packages have dependencies outside the Base category? So, even if I perform a plain Base-only installation, I get asked if dependencies shall be fullfilled, which, as a question, is more than borderline anyway. Therefore, shouldn't we put all packages Base packages depend on into Base as well? I can't find it in the archives now, but a year or two ago we talked about this in the context of libargp. There's a Base package (can't remember which one) that depends on libargp. But the consensus at the time was that we shouldn't put libargp into Base, because if the other package stopped requiring it, it wouldn't belong there on its own. So if we're talking about permanently adding those other packages to the Base category, I don't agree. But it we're talking about adding them to Base automatically only as long as another Base package requires them, then I guess that's fine. Andrew
Re: [HEADSUP] Base category
On Dec 6 13:21, Ken Brown wrote: On 12/6/2014 12:57 PM, Corinna Vinschen wrote: On Dec 6 12:40, Ken Brown wrote: On 12/6/2014 11:57 AM, Corinna Vinschen wrote: Hi, isn't it rather annoying that even Base packages have dependencies outside the Base category? So, even if I perform a plain Base-only installation, I get asked if dependencies shall be fullfilled, which, as a question, is more than borderline anyway. Therefore, shouldn't we put all packages Base packages depend on into Base as well? That makes sense to me. The popup about dependencies could be confusing for someone installing Cygwin for the first time. ACK. Also, can we automate this? I'm not sure that's a good idea. If the dependencies of a Base package change, it's probably good for this to be noticeable, in case it was due to a packaging error. Uh, I was only talking about automating to add the categories to all affected packages once and get a list of packages to send to this list. I just did a test install on each architecture and extracted the info from setup.log. Both arches: _autorebase _update-info-dir bzip2 ca-certificates groff less libargp libattr1 libblkid1 libbz2_1 libffi6 libgcc1 libgdbm4 libgmp10 libiconv libiconv2 libintl8 liblzma5 libmpfr4 libncursesw10 libopenssl100 libp11-kit0 libpcre1 libpipeline1 libpopt0 libsmartcols1 libstdc++6 libtasn1_6 libuuid1 lynx p11-kit p11-kit-trust popt xz zlib0 32-bit only: libcharset1 libncurses10 64-bit only: libreadline7 Cool, thanks. These are much less packages than I feared. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1NSdstz6Yd.pgp Description: PGP signature
Re: [HEADSUP] Base category
On Dec 6 13:52, Andrew Schulman wrote: isn't it rather annoying that even Base packages have dependencies outside the Base category? So, even if I perform a plain Base-only installation, I get asked if dependencies shall be fullfilled, which, as a question, is more than borderline anyway. Therefore, shouldn't we put all packages Base packages depend on into Base as well? I can't find it in the archives now, but a year or two ago we talked about this in the context of libargp. There's a Base package (can't remember which one) that depends on libargp. But the consensus at the time was that we shouldn't put libargp into Base, because if the other package stopped requiring it, it wouldn't belong there on its own. So if we're talking about permanently adding those other packages to the Base category, I don't agree. But it we're talking about adding them to Base automatically only as long as another Base package requires them, then I guess that's fine. I see. This would be a matter of maintainance I guess. As the list Ken assembled shows, the number of affected packages isn't *that* big, really. The fact that a Base install will pull these packages in anyway in conjunction with a user request which allows to reply with No is what concerns me. And Ken's point about user confusion isn't something we should take lightly. Having said that, the ideal solution for this problem *might* be an extension to setup: If a package is pulled in by dependency resolution, and if this package is required by a Base package, it should be silently pulled in. OTOH, this also might be more complicated if some of the dependencies are only indirect. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpaNHiS4Z8Rq.pgp Description: PGP signature
Re: [HEADSUP] Base category
On 06/12/2014 18:52, Andrew Schulman wrote: isn't it rather annoying that even Base packages have dependencies outside the Base category? So, even if I perform a plain Base-only installation, I get asked if dependencies shall be fullfilled, which, as a question, is more than borderline anyway. Therefore, shouldn't we put all packages Base packages depend on into Base as well? I can't find it in the archives now, but a year or two ago we talked about this in the context of libargp. There's a Base package (can't remember which one) that depends on libargp. But the consensus at the time was that we shouldn't put libargp into Base, because if the other package stopped requiring it, it wouldn't belong there on its own. So if we're talking about permanently adding those other packages to the Base category, I don't agree. But it we're talking about adding them to Base automatically only as long as another Base package requires them, then I guess that's fine. I have to agree with Andrew here. Dependencies change, so decide what should be in 'Base' and let dependencies be pulled in as required. I have never been overly concerned that there are dependencies outside of 'Base'. Maybe what we should consider is removing the 'Select required packages (RECOMMENDED)' check box on the 'Resolving Dependencies' page in the installer. Under what use case is unticking this a sensible idea? Dave.
Re: [HEADSUP] Base category
David Stacey writes: I have to agree with Andrew here. Dependencies change, so decide what should be in 'Base' and let dependencies be pulled in as required. I have never been overly concerned that there are dependencies outside of 'Base'. We could make setup pull all dependencies of Base packages in silently. That would remove the surprise moment to new users; but we would need to be extra careful not to pull in spurious dependencies like Perl again or risk upsetting the experienced users. Maybe what we should consider is removing the 'Select required packages (RECOMMENDED)' check box on the 'Resolving Dependencies' page in the installer. Under what use case is unticking this a sensible idea? Since setup doesn't have something like soft dependencies or recommends, you can sometimes avoid pulling in large parts of the distribution by skipping one key dependency (like Perl, for instance). That will give you reduced functionality of course, but if you know what you're doing it may be what you really want. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [HEADSUP] Base category
On 06/12/14 21:19, Achim Gratz wrote: Maybe what we should consider is removing the 'Select required packages (RECOMMENDED)' check box on the 'Resolving Dependencies' page in the installer. Under what use case is unticking this a sensible idea? Since setup doesn't have something like soft dependencies or recommends, you can sometimes avoid pulling in large parts of the distribution by skipping one key dependency (like Perl, for instance). That will give you reduced functionality of course, but if you know what you're doing it may be what you really want. Ah, fair enough. Some folk like to keep a minimal install. Dave.
