| Git Clone URL: | https://aur.archlinux.org/neovim-git.git (read-only, click to copy) |
|---|---|
| Package Base: | neovim-git |
| Description: | Fork of Vim aiming to improve user experience, plugins, and GUIs |
| Upstream URL: | https://neovim.io |
| Keywords: | editor |
| Licenses: | custom:neovim |
| Conflicts: | neovim |
| Provides: | neovim, vim-plugin-runtime |
| Submitter: | fhahn |
| Maintainer: | Farzat |
| Last Packager: | Farzat |
| Votes: | 256 |
| Popularity: | 1.59 |
| First Submitted: | 2014-02-21 19:50 (UTC) |
| Last Updated: | 2024-03-11 05:36 (UTC) |
There is a build failure:
/usr/bin/luajit: ...-git/src/neovim/src/nvim/generators/gen_api_dispatch.lua:196: attempt to call field 'encode' (a nil value)
I am guessing it is due to this commit and is related to mpack. Don't know how to fix it, though. Any ideas?
If you submit an orphan request for a package that's been out of date more than some threshold (I believe 6 months?) then it will automatically get orphaned. Thanks for reaching out.
@eclairevoyant Thanks!
About the hypothetical package, I was suggesting it before I found out abandoned packages could be adopted so easily; I think it would have some hypothetical differences (more stability of neovim and the aur package, etc.) over the nightly binaries and master, but not substantial enough.
@REmorin I've orphaned and adopted neovim-nightly-bin, I can fix the issues there.
Regarding your suggested hypothetical package, rule #1 of the AUR is it should be a useful package; is there some substantial difference with using the nightly branch instead of the master branch?
@eclairevoyant hi, could you create a package named neovim-nightly-git based on the nightly github tag/tree?
Currently there're 2 packages: neovim-nightly-bin and nvim-nightly, while they still work and fetch the latest version, they are very poorly maintained, if maintained at all.
nvim-nightly is out-of-date because it doesn't have a pkgver() function and the maintainer stopped bumping the version himself; it also has some weird issues like trailing commas in keywords and the name itself (why nvim- instead of neovim-?).
neovim-nightly-bin is more appropriate in this case, but it's wrongly flagged out-of-date and I think the maintainer should bump the AUR version to any 0.9.0…, so people would stop wrongly flagging it but the maintainer seems to be gone forever. Also, some people had some build issues and with the maintainer gone, there is nobody to help them.
Also, these are the binary packages, I think it would be cool if we had a source neovim nightly package.
Btw, maybe you could become the maintainer of neovim-nightly-bin and send an orphan request?
@nsmks1508 you're right that the rename makes no sense. Looks like I forgot to do a full clean up of this package when I originally adopted it; I'll take a look this week.
While I don't see the point of the rename as-is, it doesn't cause any problems.
source=("${pkgname}::git+https://github.com/neovim/neovim.git")
This cause the problem that pkgver() can't check source version
Just keep it simple: source=("git+https://github.com/neovim/neovim.git")
And then change:
pkgver() {
cd "${pkgname}"
...
to
pkgver() {
cd neovim
...
And change:
build() {
...
cmake -S"${pkgname}" -Bbuild \
...
to
build() {
...
cmake -Sneovim -Bbuild \
...
And
package() {
...
cd "${srcdir}/${pkgname}"
...
to
package() {
...
cd "${srcdir}/neovim"
...
@Scimmia is correct, this has not been and will likely never be supported in makepkg itself; see the wiki.
I fundamentally disagree with cloning in prepare(), because any proper AUR helper (which, even though officially unsupported, realistically many of the users use for the sake of automating ultimately repetitive tasks) will wipe out $srcdir. For example, if a patch needs to be reapplied, it should be reapplied on the original source, so if we put a clone command in package(), it will re-download the entire repo (or whatever applicable part of the repo, but point stands).
On the other hand, those helpers can take advantage of whatever is downloaded to $SRCDEST and ultimately cache that for future builds (which means, for VCS packages, it will simply fetch the new changes in rather than re-downloading the entire repo/branch/whatever).
This type of discussion has been had on the mailing list before, and unless makepkg adds support for single-branch cloning within the source array, I don't think there's a good reason to make changes here.
Secondly, keeping it in the source array makes it explicit where the PKGBUILD is downloading from directly on aurweb. Yes, users are supposed to read all the PKGBUILDs in full, but keeping it in the source array avoids masking what we are doing.
Either way, a maintainer has to decide one way or another, one option downloads too much in the short term but less in the long term, the other does the opposite. I choose to go with the first option. Assuming you are not using AUR helpers, you can clone this package and make the modifications yourself on your personal machine if you have a specific need. If you are using AUR helpers, any decent one will allow you to review and make edits to the PKGBUILD before building them (aurutils is a good option for this).
"I believe PKGBUILD has support for cloning a subset of a git repo."
It does not.
Pinned Comments
fwalch commented on 2016-07-04 19:52 (UTC) (edited on 2016-07-04 19:54 (UTC) by fwalch)