X-Spam-Check-By: sourceware.org Date: Mon, 26 Jun 2006 11:47:08 -0400 (EDT) From: Igor Peshansky Reply-To: cygwin AT cygwin DOT com To: Marshall Abrams cc: cygwin AT cygwin DOT com Subject: Re: Suggestion: split vim support files into separate package In-Reply-To: <000301c69932$565feee0$080a17d1@yourbes5v9ftq9> Message-ID: References: <000301c69932$565feee0$080a17d1 AT yourbes5v9ftq9> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Mon, 26 Jun 2006, Marshall Abrams wrote: > I want to suggest splitting vim support files (installed in > /usr/share/vim/vim) into a separate package from the > binaries. There are two versions of vim binaries in Cygwin, the no-X > version (vim), and the version with X GUI compiled in (gvim), but their > (major) versions are not always in sync (as recent posts on this list > illustrated). The problem is that if you install the newer version in > the most obvious way, the support files for the older version get > deleted, and all of a sudden the older version which you're still using > doesn't function properly. (For example, at the moment, installing the > latest no-X vim in Cygwin, at version 7.0, deletes the support files for > the latest version of gvim in Cygwin, at version 6.4.) > > Of course there are various ways to work around this problem without too > much trouble, but why not just make the support files a separate package > with dependencies linking both versions of the binaries to it. That > way, I assume, the older support files wouldn't go away if something > still depends on them. Sorry, but that's not how it works. Cygwin package dependences are not implicitly versioned, so if you release a newer version of the support files package, it will overwrite the old one, just as it does in the current setup. Even now, gvim requires vim, and that doesn't help, as you can see. The vim and gvim packages are really intended to be released in lock-step. The gvim maintainer was already asked to prepare a 7.0 version -- we'll just have to wait until he does. An alternative is to introduce explicitly versioned dependencies (i.e., where the version becomes part of the package name). This is already done for shared library packages -- whenever a new version gets released, a compatibility package with the old version gets split off. The problem is that this is quite a bit of effort, , and the vim/gvim maintainers are (appropriately) not willing to invest that much effort. While it's necessary for shared libraries (since you never know who will be needing the old DLL version), I don't think this would be too useful for two sister packages like vim and gvim. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu | igor AT watson DOT ibm DOT com ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- 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/