Robert Collins wrote: >On Wed, 2002-08-14 at 00:11, Nicholas Wourms wrote: > >>Robert Collins wrote: >> >> >>>On Wed, 2002-08-14 at 00:02, Nicholas Wourms wrote: >>> >>> >>> >>> >>>>Well that may be the way it should be, but the reality of the situation >>>>is this: >>>> >>>> >>>> >>>Check the source luke. >>> >>> >>Source != Reality >> > >Ha!. Source released under the GPL had d**n well better == reality, or >we're breaking the licence. > What I mean to say is that, despite one's best efforts, compiled source doesn't always behave as one had intended. Of course it will act as it is written, it just may not seem apparent that the way it acts != the way you intended it to act.
> > >>Why on earth would setup be saying it is uninstalling but not really >>uninstalling? >> > >Is is uninstalling, but not as an uninstall, rather as the first part of >an upgrade. I've already said this in this conversation. > I wasn't disputing the fact that this is the way you intended it. >>It sure does act like it is uninstalling, including >>long pauses of activity for the larger packages. And if your >>assertions were correct, wouldn't the uninstall of the next package >>happen right after the install of the previously updated package? >> > >Yes. And it should. You've also prodded me into finding a bug. Thanks. > Why is this behaviour considiered a bug? It seems quite logical to me. It allows for the usage that Corinna had desired. Otherwise, there is no way to garuntee that updating a package later in the alphabet won't trump an earlier update's install. Pretty handy when you want to fix a conflicting package f*$kup. > >>AFAICT, this is not what is happening. Be aware that I'm using the >>release version of setup, not HEAD or a snapshot. >> > >It's been like this for 3 full releases. See install.cc. >See your log files. They'll show I was completely wrong! > >FYI there are three loops in install.cc. >One for uninstalls >One for inplace replacements >One for installs. > >The uninstall checks is coded wrongly and triggering on replacements. > >Doh. > >So emacs will squeeze by for now. > Well, I guess given the fact that this is not a permanent feature, the whole point is rather moot [I would, however, suggest that this become a permanent feature...]. People will just have to remeber to reinstall ctags. Cheers, Nicholas
