Minor modifications from latexsuite-1.5.ebuild. Uses the latest released version which includes *many* bug fixes and enhancements (version 1.5 dates back to dec-2003). For details see the changelog at http://vim-latex.sourceforge.net/vimfiles/ftplugin/latex-suite/ChangeLog The ebuild seems to work ok on my setup (x86, vim-6.4, gvim *not installed*, several other plugins installed), but I haven't done extensive testing.
Created attachment 79398 [details] latexsuite-1.5.20060124 (Update)
Is there any reason upstream can't do a proper release?
I already asked to the mailing list about this and I am waiting for an answer. When/if I get an answer, I'll forward it here.
Below you'll find the answer given by the latexSuite package developer when asked about the package's version naming scheme. Acording to his answer, see below, the release named latexSuite20060124 corresponds to version 1.8.07. Note that he also considers the naming scheme based on the date more robust. original mail follows ================================================================== On 11/02/06 22:46, Srinath Avadhanula wrote: > The versioning scheme of vim-latex leaves a little to be desired. Of > late, there are two distinct ways to define the "version" of > vim-latex. One is the output of the :TVersion command which will show > you a number like 1.8.02 or something similar. The other is the date > on the actual file you download. The reason the release is made with > the time-stamp is that it was simply easier to make quick releases > this way. In particular, the download.inc PHP code just checks for the > latest file names of the pattern latexSuite200*.tar.gz and proceeds to > dynamically generate a link to them. All I need to do to make a > release is to make a CVS commit and do > > :make release > > I have been pretty careful nowadays to keep updating the internal > version number (maintained in ftplugin/latex-suite/version.vim) after > every release. So you should be able to use either of the two as the > official "version". Personally, the timestamp is a teensy bit more > robust because it does not rely on me remembering to update > version.vim. > > Thanks, > Srinath > > On 2/10/06, jorges <jorgesmbox-ml@yahoo.es> wrote: > >>Hi, >>I've been using vim-latex for more than a year now, although there's >>plenty of things I haven't used yet. Now, going to the purpose of this post: >> >>- Have you changed the version naming scheme? It seems that all recent >>releases follow a different convention, i.e. latexSuite20060124, than >>the, now old, previous ones, i.e. 1.5. This might seem like a dumb >>question, but I ask because the linux distribution I use (Gentoo Linux) >>still has version 1.5 as the latest *released* version. Is there a >>conceptual distinction between the two naming schemes, i.e new features >>vs. bug fixes release types? I want to have this clear before I try to >>convince the maintainers to keep updating to the latests versions and >>probably switching to the new naming scheme. >> >>Regards, >> >>jorge
Okay, guess we'll go with this then. Some things that will need changing: * KEYWORDS should be dropped to all ~ on a bump * DESCRIPTION is triggering the "too loooonnnnng!" warning. "vim plugin: a comprehensive set of tools to view, edit and compile LaTeX documents" says the same thing in fewer words. * I'm wondering whether we should just name the ebuild 200blah rather than including the 1.5. Problem is, if we do this and upstream switches to non-date versions, we're screwed.
(In reply to comment #5) > Okay, guess we'll go with this then. Some things that will need changing: > > * KEYWORDS should be dropped to all ~ on a bump > * DESCRIPTION is triggering the "too loooonnnnng!" warning. "vim plugin: a > comprehensive set of tools to view, edit and compile LaTeX documents" says the > same thing in fewer words. OK, I attach a new version of the build including these changes. I am not sure wether you expected me to introduce them or not. If not, let me know for next time. > * I'm wondering whether we should just name the ebuild 200blah rather than > including the 1.5. Problem is, if we do this and upstream switches to non-date > versions, we're screwed. Naming the ebuild by the build date is the easiest, but you're right about the switch (it happened already, isn't it?). Another choice is to keep using the internal version number as was done until now, i.e. 1.8.07 for this release, but the problem somehow remains if the author *forgets* to update it and it might be confusing for the user because the vim-latex web site now *only* advertizes the build date. Combining both the internal version and the build date, i.e. this release would be 1.8.07.20060124 or something, would be more robust but also quite ugly. I guess this is your call now. I left this part as it was before.
Created attachment 80002 [details] latexsuite-1.5.20060124 (Update) * Dropped KEYWORDS to ~ for all platforms * Reduced description lenght All changes as adviced by ciaranm
Thanks. I also switched to using versionator rather than hardcoding the 1.5.
