| 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 (gpanders) |
| Last Packager: | gpanders |
| Votes: | 257 |
| Popularity: | 0.98 |
| First Submitted: | 2014-02-21 19:50 (UTC) |
| Last Updated: | 2024-09-04 00:24 (UTC) |
@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.
I have noticed then when I install this package, it clones the whole neovim repo and all its history, rather than the HEAD of a specific branch. I think this could be a nice quality of life change, which should significantly improve the download speed when installing this package.
I believe PKGBUILD has support for cloning a subset of a git repo. The simplest of which is probably just running a custom git command like git clone git@github.com:neovim/neovim.git --single-branch --branch master. Some quick googling shows me that there is no support for pull requests in the AUR, but I could try putting together a patch if that is helpful to the maintainer.
We get it, no need to submit the same orphan request and post the same patch dozens of times (@pjvds @just1602 not even the correct patch, by the way). Remember that Arch is run by volunteers and spamming will not get things moving faster. Posting errors here is also silly if you have not built in a clean environment.
Instead, what you can do is edit the PKGBUILD on your own system to update the deps and makedeps (this is a VCS package after all, you do not need to wait for it to be updated on aurweb, because editing it once will work for the future unless the build process changes), and always build in a clean chroot.
Edit: I've adopted the package and corrected the deps.
If you are trying to use the below fixes and they are not working because it still detects it as libvterm 0.1.4 then do this.
Go into src/build
remove CMakeCache.txt
try the fixes again
Pinned Comments
fwalch commented on 2016-07-04 19:52 (UTC) (edited on 2016-07-04 19:54 (UTC) by fwalch)