This is the mail archive of the
mailing list for the Cygwin project.
Re: Suggestion: split vim support files into separate package
- From: Igor Peshansky <pechtcha at cs dot nyu dot edu>
- To: Marshall Abrams <mars at gwu dot edu>
- Cc: cygwin at cygwin dot com
- Date: Mon, 26 Jun 2006 11:47:08 -0400 (EDT)
- Subject: Re: Suggestion: split vim support files into separate package
- References: <000301c69932$565feee0$080a17d1@yourbes5v9ftq9>
- Reply-to: 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<major-version>) 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
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, <http://cygwin.com/acronyms/#SHTDI>,
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.
|\ _,,,---,,_ firstname.lastname@example.org | email@example.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