Re: GNU emacs 21.2-3 packages available
On Mon, Aug 12, 2002 at 06:45:32PM -0400, Joe Buehler wrote: Joe Buehler wrote: New GNU emacs packages are available for upload to sources.redhat.com at: http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs/emacs-21.2-3-src.tar.bz2 http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs/emacs-21.2-3.tar.bz2 http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs/setup.hint http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs-el/emacs-el-21.2-3.tar.bz2 http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs-el/setup.hint http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs-X11/emacs-X11-21.2-3.tar.bz2 http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs-X11/setup.hint This version fixes tty subprocess functionality: telnet, ange-ftp, gnus and the like. Uploaded. Please add a note to your announcement that the deinstallation of the old package will drop ctags exectuables so that a reinstall of that package would be necessary. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: GNU emacs 21.2-3 packages available
Corinna Vinschen wrote: On Mon, Aug 12, 2002 at 06:45:32PM -0400, Joe Buehler wrote: Joe Buehler wrote: New GNU emacs packages are available for upload to sources.redhat.com at: http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs/emacs-21.2-3-src.tar.bz2 http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs/emacs-21.2-3.tar.bz2 http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs/setup.hint http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs-el/emacs-el-21.2-3.tar.bz2 http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs-el/setup.hint http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs-X11/emacs-X11-21.2-3.tar.bz2 http://68.100.179.154:3000/cygwin/emacs-21.2-3/emacs-X11/setup.hint This version fixes tty subprocess functionality: telnet, ange-ftp, gnus and the like. Uploaded. Please add a note to your announcement that the deinstallation of the old package will drop ctags exectuables so that a reinstall of that package would be necessary. Would it drop ctags with requires: ctags cygwin in the hint file? Earnie.
Re: GNU emacs 21.2-3 packages available
Corinna Vinschen wrote: Uploaded. Please add a note to your announcement that the deinstallation of the old package will drop ctags exectuables so that a reinstall of that package would be necessary. Corinna, maybe I misunderstand, but only the main package for emacs-21.2-3 is on sources.redhat.com. The others are not there. I split the single original package into several, like XFree86 does it, with subdirectories. One of my concerns was whether I did that correctly. Joe Buehler
Re: GNU emacs 21.2-3 packages available
On Tue, Aug 13, 2002 at 08:05:13AM -0400, [EMAIL PROTECTED] wrote: Corinna Vinschen wrote: Uploaded. Please add a note to your announcement that the deinstallation of the old package will drop ctags exectuables so that a reinstall of that package would be necessary. Corinna, maybe I misunderstand, but only the main package for emacs-21.2-3 is on sources.redhat.com. The others are not there. Yes, they are. release/emacs/emacs-el, release/emacs/emacs-X11. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: GNU emacs 21.2-3 packages available
On Tue, Aug 13, 2002 at 07:50:32AM -0400, Nicholas Wourms wrote: Earnie Boyd wrote: Would it drop ctags with requires: ctags cygwin in the hint file? Yes, because the ctags version hasn't been bumped, so the installer thinks it is still there eventhough the removal of the old emacs package deletes them. The new package, of course, doesn't reinstall them. Hmm, perhaps it *is* better to bump the version?!? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: GNU emacs 21.2-3 packages available
On Tue, 2002-08-13 at 22:26, Corinna Vinschen wrote: Hmm, perhaps it *is* better to bump the version?!? Yes. Rob signature.asc Description: This is a digitally signed message part
Re: GNU emacs 21.2-3 packages available
On Tue, Aug 13, 2002 at 10:32:13PM +1000, Robert Collins wrote: On Tue, 2002-08-13 at 22:28, Robert Collins wrote: On Tue, 2002-08-13 at 22:26, Corinna Vinschen wrote: Hmm, perhaps it *is* better to bump the version?!? Yes. But it won't help. Sorry. The reason is that ctags will get reinstalled *first*, leaving emacs to still break the user environment. Doesn't setup first deinstall all old and then install all new packages? In that case everything should be fine. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: GNU emacs 21.2-3 packages available
Corinna Vinschen wrote: On Tue, Aug 13, 2002 at 10:32:13PM +1000, Robert Collins wrote: On Tue, 2002-08-13 at 22:28, Robert Collins wrote: On Tue, 2002-08-13 at 22:26, Corinna Vinschen wrote: Hmm, perhaps it *is* better to bump the version?!? Yes. But it won't help. Sorry. The reason is that ctags will get reinstalled *first*, leaving emacs to still break the user environment. Doesn't setup first deinstall all old and then install all new packages? In that case everything should be fine. It does, I think Robert's having a wee bit of memory loss. He better look into some parity memory :-D. Cheers, Nicholas
Re: GNU emacs 21.2-3 packages available
Robert Collins wrote: On Tue, 2002-08-13 at 23:22, Nicholas Wourms wrote: It does, I think Robert's having a wee bit of memory loss. He better look into some parity memory :-D. An upgrade is != to an uninstall and install. Setup treats upgrades as atomic actions per package. Then why is it that when I upgrade, it always says it is removing all the files from each previous packages? It does this for each package I've got checked to upgrade. Only after it finishes that, does it install the upgraded packages. Either the dialogue lies or something isn't right with my installer. Cheers, Nicholas
Re: GNU emacs 21.2-3 packages available
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. 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. 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. 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. Rob signature.asc Description: This is a digitally signed message part
Re: GNU emacs 21.2-3 packages available
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
Re: GNU emacs 21.2-3 packages available
On Wed, 2002-08-14 at 00:34, Nicholas Wourms wrote: Robert Collins wrote: 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. Now that, that I agree with. 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. Because it's actually worse. The cause of the conflicting package f***up is setup not checking for conflicts. So that can and will be addressed in other fashions. The reason to make upgrades atomic and done one package at a time is to deal with cases like the following: A pre-removal script (which *should* trigger on upgrades) may require binaries from another package being upgraded. Unless that other package is installed again at the time of the pre-removal script triggering, bad things will happen. Rob signature.asc Description: This is a digitally signed message part
Re: GNU emacs 21.2-3 packages available
Argh - sorry bad gareth sent copys to authors as well as list. Gareth - adds to your spam by appologising :P. _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: GNU emacs 21.2-3 packages available
On Wed, 2002-08-14 at 12:41, Gareth Pearce wrote: alphabetical order can still obviously screw this up anyway, no way to work this perfectly until the full versioned dependency set comes in - pre-removal-depends post-install-depends ... etc. That level of depends tracking is not needed. The depends is versioned in HEAD already. Hope someone has a nice algorithm for multi-dependency ordering satifaction and circular dependency detection. It's a DAG, and there are libraries for that. Still it is an excercise. Rob signature.asc Description: This is a digitally signed message part
