I'd like to get a version bump on bash-support-3.8 here into portage, however, somebody has taken the default *.zip package of this vim script and imported into a github... making it extremely difficult for me (and other users) to package and test themselves. As such, all I can suggest is rename the ebuild filename to bash-support-3.8.ebuild and give it a whirl -- I doubt there'll be issues as it's quite simple. Another reason to get this into portage, the script files are now *global* and the script apparently installes a user Template in $HOME. This would make this package distro packaging friendly for the first time. (c-support-5.16.1 also recently got these fixes as well - not sure about it installing a local $HOME Template thought.) Reproducible: Always
OK. I've found I had mirrored the original ebuild files locally elsewhere here. I would suggest, instead of deleting the old SRC_URI, just to comment it out so users can uncomment to test their ebuild modifications locally, since the latest bash-support will not be imported into the github until the next ebuild is published into Portage. ie: #SRC_URI="http://www.vim.org/scripts/download_script.php?src_id=15125 -> ${P}.zip" Eeks! I found some major changes without a -r? update. (Unpacking functions needed for using the tar.gz files.) Is there a way users can work around this so they can update & test their ebuilds before submitting an ebuild to bugs.gentoo.org? As far as bash-support-3.8, I've noticed a couple bugs I just filed upstream: 1) I found this version installed globally and on first bash script file creation using 'vim test.sh', this version creates the folder $HOME/.vim/bash-support/templates folder but does not copy over the system Templates file. ie: if !$HOME/.vim/bash-support/templates/Templates; then mkdir -p $HOME/.vim/bash-support/templates/Templates && cp /usr/share/vim/vimfiles/bash-support/templates/Templates $HOME/.vim/bash-support/templates fi Or: cp ${PREFIX}/share/vim/vimfiles/bash-support/templates/Templates $HOME/.vim/bash-support/templates (A possible fix for us packing would be to include einfo about a custom user $HOME/.vim/bash-support/templates file. But would rather wait until I hear back from the author as to whether the above is possible, which is likely, but may impact the wording of einfo.) 2) Another unusual item, when I do 'vim test.sh' and then quit without writing (ie. !q), vim writes test.sh here anyways! (I don't think this is my doing, because doing 'vim blah' without the .sh extension successfully quits without writing.) (For us packaging, this might be considered a security risk -- ie. a user writes to /etc, but wants to discard changes instead of writing.)
(In reply to comment #1) > OK. I've found I had mirrored the original ebuild files locally elsewhere here. > > I would suggest, instead of deleting the old SRC_URI, just to comment it out so > users can uncomment to test their ebuild modifications locally, since the > latest bash-support will not be imported into the github until the next ebuild > is published into Portage. The github repos are not connected to portage/Gentoo in anyway. They are just used currently so we can have a saner method of detecting version updates (with a bit of lag time due to time between scans) and have unchanging SRC_URI variables. When pulling directly from vim.org, the SRC_URI changes for every version and the scripts are packaged in an assortment of vimball, zip, tarball, and straight vim files which can change between versions. That is why previously most scripts were tarballed and mirrored on Gentoo infra. I've been working on rewriting the script used by the github folks to do scanning and tarballing for Gentoo specifically, but obviously it's not done yet. :)
(In reply to comment #2) > When pulling directly from vim.org, the SRC_URI changes for every version I should note that by this I mean they use a new number for the src_id for every new script uploaded to vim.org which probably is the total script count uploaded to vim.org or something like that. Therefore when bumping ebuilds using that type of SRC_URI one always has to update that "random" number which amounts to annoying churn when maintaining a lot of packages.
Well, now I'm glad you're heading in this direction and fully automating and properly tarballing the VIM scripts. And, since it's separate of gentoo.org, it might mean I can get the ball rolling faster when there's problems. (No offense, but I just hate red tape.) Cheers! Just wish Gentoo would have published a news item on this, so you don't have to repeat yourself!
Added to CVS.
Forgot about this. Heard back from the Author/Maintainer and this, and the omission of creating the $HOME/.vim/bash-support/templates/Templates is normal activity. The plugins (b-support and cvim?) will use the global Template configuration file for initial file creations, unless the user manually makes the $HOME folder, copies over the template and modifies it themselves. As such, einfo notifying the user to do this task might be advisable! Also the Author confirmed I found a long-term bug with bash-support creating new files without VIM being given the :w (write command). Just to assure, pre-existing files were not being modified and this seems to occur only when templates are initially pulled into newly created files. I would imagine this will be fixed on the next release and the author was too concerned about it.
