* Blocking a base package from installing @ 2016-10-06 17:15 Chris Sutcliffe 2016-10-06 17:28 ` Hans-Bernhard Bröker ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Chris Sutcliffe @ 2016-10-06 17:15 UTC (permalink / raw) To: The Cygwin Mailing List I'm using a self compiled vim, so I uninstalled vim-minimal. Every time I run setup to get the latest updates, setup attempts to reinstall vim-minimal - is there a way to make setup ignore vim-minimal? Thanks, Chris -- Chris Sutcliffe -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Blocking a base package from installing 2016-10-06 17:15 Blocking a base package from installing Chris Sutcliffe @ 2016-10-06 17:28 ` Hans-Bernhard Bröker 2016-10-06 17:37 ` Achim Gratz 2016-10-06 19:02 ` Andrey Repin 2 siblings, 0 replies; 16+ messages in thread From: Hans-Bernhard Bröker @ 2016-10-06 17:28 UTC (permalink / raw) To: cygwin Am 06.10.2016 um 16:57 schrieb Chris Sutcliffe: > I'm using a self compiled vim, so I uninstalled vim-minimal. Every > time I run setup to get the latest updates, setup attempts to > reinstall vim-minimal - is there a way to make setup ignore > vim-minimal? With the alternative being to pick a fight with the tools, wouldn't it be a whole lot more straightforward to install your own vim with --prefix $HOME or /usr/local instead? That's what I do with basically all packages I install from sources; and using stow to manage them even makes that reasonably painless. -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Blocking a base package from installing 2016-10-06 17:15 Blocking a base package from installing Chris Sutcliffe 2016-10-06 17:28 ` Hans-Bernhard Bröker @ 2016-10-06 17:37 ` Achim Gratz 2016-10-06 18:30 ` Linda Walsh 2016-10-06 19:02 ` Andrey Repin 2 siblings, 1 reply; 16+ messages in thread From: Achim Gratz @ 2016-10-06 17:37 UTC (permalink / raw) To: cygwin Chris Sutcliffe writes: > I'm using a self compiled vim, so I uninstalled vim-minimal. Every > time I run setup to get the latest updates, setup attempts to > reinstall vim-minimal - is there a way to make setup ignore > vim-minimal? Yes, at least two. 1. Build a proper package and give it a higher version number than Cygwin's own Vim. 2. Fake the installation of vim-minimal in /etc/setup/installed.db and give that fake installation some high version number. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Blocking a base package from installing 2016-10-06 17:37 ` Achim Gratz @ 2016-10-06 18:30 ` Linda Walsh 2016-10-06 18:35 ` Eric Blake 2016-10-06 19:15 ` Achim Gratz 0 siblings, 2 replies; 16+ messages in thread From: Linda Walsh @ 2016-10-06 18:30 UTC (permalink / raw) To: cygwin Achim Gratz wrote: > Chris Sutcliffe writes: >> I'm using a self compiled vim, so I uninstalled vim-minimal. Every >> time I run setup to get the latest updates, setup attempts to >> reinstall vim-minimal - is there a way to make setup ignore >> vim-minimal? > > Yes, at least two. > > 1. Build a proper package and give it a higher version number than > Cygwin's own Vim. > > 2. Fake the installation of vim-minimal in /etc/setup/installed.db and > give that fake installation some high version number. --- Both of which are "lying" to the package manager, to get it to NOT install an inferior (from the standpoint of not containing the user-desired modifications/features) package. It should be possible to "LOCK" a package (base or not), to prevent it from being removed/updated/installed or changed by setup, no? -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Blocking a base package from installing 2016-10-06 18:30 ` Linda Walsh @ 2016-10-06 18:35 ` Eric Blake 2016-10-06 19:15 ` Achim Gratz 1 sibling, 0 replies; 16+ messages in thread From: Eric Blake @ 2016-10-06 18:35 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 395 bytes --] On 10/06/2016 01:22 PM, Linda Walsh wrote: > It should > be possible to "LOCK" a package (base or not), to prevent it from > being removed/updated/installed or changed by setup, no? Technically possible if someone were to write patches for it to do so. Are you volunteering? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 604 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Blocking a base package from installing 2016-10-06 18:30 ` Linda Walsh 2016-10-06 18:35 ` Eric Blake @ 2016-10-06 19:15 ` Achim Gratz 2016-10-07 0:16 ` Linda Walsh 1 sibling, 1 reply; 16+ messages in thread From: Achim Gratz @ 2016-10-06 19:15 UTC (permalink / raw) To: cygwin Linda Walsh writes: >> 1. Build a proper package and give it a higher version number than >> Cygwin's own Vim. >> >> 2. Fake the installation of vim-minimal in /etc/setup/installed.db and >> give that fake installation some high version number. > --- > Both of which are "lying" to the package manager, to get it to > NOT install an inferior (from the standpoint of not containing > the user-desired modifications/features) package. It should > be possible to "LOCK" a package (base or not), to prevent it from > being removed/updated/installed or changed by setup, no? Not really, although there is some skipping of intermediate steps involved. By building your own package you introduce a second package source (like Cygport does). The two package sources can only coexist if either the package versions are all different (note: version here includes the "build number") or the package sets are disjunct and dependencies are only present from the "second source" into the first. If you were to change the packaging of an existing package in the base package source, you'd have to provide obsolescence packages for those packages you no longer provide content for. The two suggestions just produce the end result of doing that with different amounts of not actually doing all the work that would be required (and if you break your system you get to keep the pieces). Now, that last question of yours: No, the package manager should never allow you to not install a base package. These are in category "Base" precisely so the rest of the system can rely on the functionality provided. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Blocking a base package from installing 2016-10-06 19:15 ` Achim Gratz @ 2016-10-07 0:16 ` Linda Walsh 2016-10-07 11:04 ` Andrey Repin 2016-10-07 22:04 ` Blocking a base package from installing Hans-Bernhard Bröker 0 siblings, 2 replies; 16+ messages in thread From: Linda Walsh @ 2016-10-07 0:16 UTC (permalink / raw) To: cygwin; +Cc: Achim Gratz Achim Gratz wrote: > Now, that last question of yours: No, the package manager should never > allow you to not install a base package. These are in category "Base" > precisely so the rest of the system can rely on the functionality > provided. --- And what other programs will stop functioning if vim is not installed? If I compile and install a version of vim on my system, why would I want to put it in a location like /usr/local where it might not be used -- all the time? I'm the only user on my system -- whether I run as a user or as root, or whatever, I'm not doing this for someone else. If I try to edit a file using 'vim' from the explorer menu, will it invoke my vim in /usr/local -- of course not. Installing some private copy where all the rest of the system will ignore it, is asking for headaches. How many people do you think are installing cygwin on servers to be used by many people, vs. their personal machines to only be used by them? But back to the 1st Q. What other programs will fail to work if the base-version of vim isn't installed? -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Blocking a base package from installing 2016-10-07 0:16 ` Linda Walsh @ 2016-10-07 11:04 ` Andrey Repin 2016-10-07 22:40 ` intelligent following of directions, or following them by rote Linda Walsh 2016-10-07 22:04 ` Blocking a base package from installing Hans-Bernhard Bröker 1 sibling, 1 reply; 16+ messages in thread From: Andrey Repin @ 2016-10-07 11:04 UTC (permalink / raw) To: Linda Walsh, cygwin Greetings, Linda Walsh! > Achim Gratz wrote: >> Now, that last question of yours: No, the package manager should never >> allow you to not install a base package. These are in category "Base" >> precisely so the rest of the system can rely on the functionality >> provided. [snip] > But back to the 1st Q. What other programs will fail to work > if the base-version of vim isn't installed? The question is not about vim, the question is about base category in general. It's vim only now, tomorrow it'll be something else. You have to stop and draw the line somewhere, if you, as a package maintainer, want a predictable behavior for all future installations. -- With best regards, Andrey Repin Friday, October 7, 2016 13:28:54 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* intelligent following of directions, or following them by rote... 2016-10-07 11:04 ` Andrey Repin @ 2016-10-07 22:40 ` Linda Walsh 2016-10-08 18:45 ` Brian Inglis 2016-10-09 4:35 ` Erik Soderquist 0 siblings, 2 replies; 16+ messages in thread From: Linda Walsh @ 2016-10-07 22:40 UTC (permalink / raw) To: cygwin Andrey Repin wrote: > Greetings, Linda Walsh! > >> Achim Gratz wrote: >>> Now, that last question of yours: No, the package manager should never >>> allow you to not install a base package. These are in category "Base" >>> precisely so the rest of the system can rely on the functionality >>> provided. > [snip] >> But back to the 1st Q. What other programs will fail to work >> if the base-version of vim isn't installed? > > The question is not about vim... --- But it is about vim. That's the package the user wanted to install their own version of. There is such a thing of not following rules, guidelines and instructions without thinking about the situation. If you follow things without thinking, you'll often end up screwing yourself in the long run. How many installer packages tell you to accept their "default" (always says "recommended") vs. choosing specifics? The defaults often contain items you don't want while not providing things you do. The default for Nvidia drivers is to install 3D-drivers even if you don't have a 3D screen and goggles. What's intelligent about that? > It's vim only now, tomorrow it'll be something else. --- Right, Today, it's taking a walk by the seashore, tomorrow it's jumping off a cliff. Um.. no! If you do some research and/or know a bit about what you are doing, you can stop before you jump off the cliff. > You have to stop and draw > the line somewhere, if you, as a package maintainer, want a predictable > behavior for all future installations. --- But you can't get predictable behavior now. It's running on windows (1st problem), 2nd, it doesn't follow MS-Win conventions. 3rd, Windows sends out incompatibility patches on a regular basis. Documented features in windows are ignored and overwritten in cygwin -- so you already have unpredictability. I haven't installed any updates to my system since the new user-auth/password stuff was added in because the stuff I have works now with a NT4 type samba domain controller. Above that is NT5 w/active directory -- installing LDAP and losing _easy_ control over what I already have (enough research and struggle and I might get it back, but I have other things to do that have higher priority. As for package maintainers needing some specific behavior -- if a backdoor to your system was part of the "base" system, would you stick to your "line" and install it? If you say "no", then you are using your brain and not doing it by rote. If you can do it, why shouldn't other people be able to do it on their system(s)? Another simple example -- where does one install cygwin? In the /cygwin dir (Windows says not to do that -- it wants programs in "program files" or "program files (x86)). Who do you follow? How about whether you install it in /cygwin or in "/" so files @ /etc will be in \etc on windows? Cygwin recommends installing it in /cygwin, but at one point (don't know about now), most of the devs admitted that they installed it in "/" for their personal use. Anyway, thinking about what you are doing and why things are they way they are, is important -- which is why I asked, what affect on the cygwin installation would be if you didn't install the base vim package? If you don't know the answer, then maybe the defaults are for you, but if you have an idea of what vim does and how it might be used to run the rest of cygwin, then you might experiment to find if things fail or continue to work w/o the base-vim. Just a thought. -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: intelligent following of directions, or following them by rote... 2016-10-07 22:40 ` intelligent following of directions, or following them by rote Linda Walsh @ 2016-10-08 18:45 ` Brian Inglis 2016-10-09 6:56 ` Linda Walsh 2016-10-09 4:35 ` Erik Soderquist 1 sibling, 1 reply; 16+ messages in thread From: Brian Inglis @ 2016-10-08 18:45 UTC (permalink / raw) To: cygwin On 2016-10-07 16:04, Linda Walsh wrote: > Andrey Repin wrote: >> Greetings, Linda Walsh! >>> Achim Gratz wrote: >>>> Now, that last question of yours: No, the package manager should never >>>> allow you to not install a base package. These are in category "Base" >>>> precisely so the rest of the system can rely on the functionality >>>> provided. >>> But back to the 1st Q. What other programs will fail to work >>> if the base-version of vim isn't installed? >> The question is not about vim... > But it is about vim. That's the package the user wanted to > install their own version of. > Anyway, thinking about what you are doing and why things are > they way they are, is important -- which is why I asked, what affect > on the cygwin installation would be if you didn't install the base > vim package? If you don't know the answer, then maybe the defaults > are for you, but if you have an idea of what vim does and how it might > be used to run the rest of cygwin, then you might experiment to find > if things fail or continue to work w/o the base-vim. Just a thought. Type v inside a PAGER (e.g. less or more). Run an editor on the current (long) command line in readline or shell history. Edit a commit message in any VCS. Edit crontab entries. You can change some of these if you prefer ed or emacs (EDITOR, VISUAL), and ex is a symlink to vi (vim-minimal). -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: intelligent following of directions, or following them by rote... 2016-10-08 18:45 ` Brian Inglis @ 2016-10-09 6:56 ` Linda Walsh 0 siblings, 0 replies; 16+ messages in thread From: Linda Walsh @ 2016-10-09 6:56 UTC (permalink / raw) To: cygwin Brian Inglis wrote: > On 2016-10-07 16:04, Linda Walsh wrote: >> ... what affect >> on the cygwin installation would be if you didn't install the base >> vim package? Just a thought. > > Type v inside a PAGER (e.g. less or more). > Run an editor on the current (long) command line in readline or shell > history. > Edit a commit message in any VCS. > Edit crontab entries. > You can change some of these if you prefer ed or emacs (EDITOR, VISUAL), > and ex is a symlink to vi (vim-minimal). --- Good point -- but none of those should cease to run if you are putting your own "well working" version of vim it its place -- which was where this got started in someone desiring to put their own version on their machine. FWIW, I've run my own compiled Gvim version on linux for years and had fewer problems. My linux distro supplies a version that links with various languages (ruby, python, perl, etc) -- but they don't use run-time dynamic loading, so if something happens and the versions don't match (they must match, even, the patch-levels) then neither vim nor gvim can be used as an editor. Such was sufficient reason for me to build and replace the OS-instance of vim/gvim. -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: intelligent following of directions, or following them by rote... 2016-10-07 22:40 ` intelligent following of directions, or following them by rote Linda Walsh 2016-10-08 18:45 ` Brian Inglis @ 2016-10-09 4:35 ` Erik Soderquist 2016-10-09 8:55 ` Linda Walsh 1 sibling, 1 reply; 16+ messages in thread From: Erik Soderquist @ 2016-10-09 4:35 UTC (permalink / raw) To: cygwin On Fri, Oct 7, 2016 at 6:04 PM, Linda Walsh wrote: > As for package maintainers needing some specific behavior -- > if a backdoor to your system was part of the "base" system, would you If there is a "back door" in a base package, that is a security failing and needs to be reported and fixed -- Erik -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: intelligent following of directions, or following them by rote... 2016-10-09 4:35 ` Erik Soderquist @ 2016-10-09 8:55 ` Linda Walsh 0 siblings, 0 replies; 16+ messages in thread From: Linda Walsh @ 2016-10-09 8:55 UTC (permalink / raw) To: cygwin Erik Soderquist wrote: > On Fri, Oct 7, 2016 at 6:04 PM, Linda Walsh wrote: >> As for package maintainers needing some specific behavior -- >> if a backdoor to your system was part of the "base" system, would you > > If there is a "back door" in a base package, that is a security > failing and needs to be reported and fixed --- I think you miss the point -- the point would be whether or not you believe you "need" to install and use it "as is", or if consider that maybe you want a different, "fixed" version? Whether you fix it or someone else does often depends on turn-around time and ease of user building, but I think you answer the question -- you'd take action to replace the code *rather* than living with it. Hey, I never accused, directly or obliquely, you of not using your head... ;-) -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Blocking a base package from installing 2016-10-07 0:16 ` Linda Walsh 2016-10-07 11:04 ` Andrey Repin @ 2016-10-07 22:04 ` Hans-Bernhard Bröker 2016-10-08 14:45 ` Linda Walsh 1 sibling, 1 reply; 16+ messages in thread From: Hans-Bernhard Bröker @ 2016-10-07 22:04 UTC (permalink / raw) To: cygwin Am 07.10.2016 um 02:07 schrieb Linda Walsh: > Achim Gratz wrote: >> Now, that last question of yours: No, the package manager should never >> allow you to not install a base package. These are in category "Base" >> precisely so the rest of the system can rely on the functionality >> provided. > --- > And what other programs will stop functioning if vim is not installed? Vi is, for better or for worse, the default/fall-back system editor. It is assumed to be there by every useful definition of what "Unix" is. The possibilities for things breaking if it's not there are therefore almost endless. > If I compile and install a version of vim on my system, why would I > want to put it in a location like /usr/local where > it might not be used -- all the time? Because /usr/local is the designated location for software that's not part of the organized software distribution. If you want to build your own, /usr/local is where it's supposed to go --- or $HOME if you don't have admin privileges. Unix does have a very different approach to installing programs compared to Windows, in that it collects files from various packages in a few central places: /usr/bin, /usr/etc, /etc, and so on. That approach requires consistent organization to avoid complete chaos. Distributions like Cygwin provide that organization. You mess with that at your own peril. That's why non-distribution software gets its own area to work in: /usr/local. > I'm the only user on my system -- whether I run as a user > or as root, or whatever, I'm not doing this for someone else. Did it occur to you that the system really has to support much more varied use cases than your own particular corner case? > If I try to edit a file using 'vim' from the explorer menu, will it > invoke my vim in /usr/local -- of course not. If you do set up such an explorer menu entry, it'll do whatever you tell it to. It'll only end up "of course not" working if you "of course" configure things differently than you actually wanted to. But why would anyone do that? -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Blocking a base package from installing 2016-10-07 22:04 ` Blocking a base package from installing Hans-Bernhard Bröker @ 2016-10-08 14:45 ` Linda Walsh 0 siblings, 0 replies; 16+ messages in thread From: Linda Walsh @ 2016-10-08 14:45 UTC (permalink / raw) To: cygwin Hans-Bernhard Bröker wrote: > If you do set up such an explorer menu entry, it'll do whatever you tell > it to. --- There is already such an addon for vim -- and it launches it from the system-standard location. Putting a copy in /usr/local won't be called. If you want to replace the main copy and all it's purposes/uses, you need to overwrite the system copy. > It'll only end up "of course not" working if you "of course" > configure things differently than you actually wanted to. But why would > anyone do that? --- Why would you install a system copy of vim anywhere other than in the system location? To install it in /usr/local would prevent it from working normally -- why would anyone do that? > Did it occur to you that the system really has to support much > more varied use cases than your own particular corner case? --- Not on my system. -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Blocking a base package from installing 2016-10-06 17:15 Blocking a base package from installing Chris Sutcliffe 2016-10-06 17:28 ` Hans-Bernhard Bröker 2016-10-06 17:37 ` Achim Gratz @ 2016-10-06 19:02 ` Andrey Repin 2 siblings, 0 replies; 16+ messages in thread From: Andrey Repin @ 2016-10-06 19:02 UTC (permalink / raw) To: Chris Sutcliffe, cygwin Greetings, Chris Sutcliffe! > I'm using a self compiled vim, so I uninstalled vim-minimal. Every > time I run setup to get the latest updates, setup attempts to > reinstall vim-minimal - is there a way to make setup ignore > vim-minimal? Install your vim into /usr/local, should be enough for casual use. -- With best regards, Andrey Repin Thursday, October 6, 2016 21:32:30 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2016-10-09 6:56 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-10-06 17:15 Blocking a base package from installing Chris Sutcliffe 2016-10-06 17:28 ` Hans-Bernhard Bröker 2016-10-06 17:37 ` Achim Gratz 2016-10-06 18:30 ` Linda Walsh 2016-10-06 18:35 ` Eric Blake 2016-10-06 19:15 ` Achim Gratz 2016-10-07 0:16 ` Linda Walsh 2016-10-07 11:04 ` Andrey Repin 2016-10-07 22:40 ` intelligent following of directions, or following them by rote Linda Walsh 2016-10-08 18:45 ` Brian Inglis 2016-10-09 6:56 ` Linda Walsh 2016-10-09 4:35 ` Erik Soderquist 2016-10-09 8:55 ` Linda Walsh 2016-10-07 22:04 ` Blocking a base package from installing Hans-Bernhard Bröker 2016-10-08 14:45 ` Linda Walsh 2016-10-06 19:02 ` Andrey Repin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).