Hi,
I'm maintaining the vim-full[1] package which is a vim with all the gvim features (Ruby/Lua/Python/Perl/Netbeans) but without GTK/X.
Now obviously I have to depend on vim-runtime, and I currently I have the version number pinned (just like the vim package).
However that makes upgrading vim-runtime difficult, because pacman doesn't know about the vim-full upgrade. A possible solution is to build via `makepkg -d` (ignoring the old vim-runtime version), then upgrading both vim-full and vim-runtime.
Should I just not pin the version at all (as in "partial upgrades aren't supported anyways") to avoid these problems?
Florian
[1] https://aur.archlinux.org/packages/vim-full/
On Wednesday 06 August 2014 at 14:31:40, Florian Bruhin wrote:
Hi,
I'm maintaining the vim-full[1] package which is a vim with all the gvim features (Ruby/Lua/Python/Perl/Netbeans) but without GTK/X.
Now obviously I have to depend on vim-runtime, and I currently I have the version number pinned (just like the vim package).
However that makes upgrading vim-runtime difficult, because pacman doesn't know about the vim-full upgrade. A possible solution is to build via `makepkg -d` (ignoring the old vim-runtime version), then upgrading both vim-full and vim-runtime.
Should I just not pin the version at all (as in "partial upgrades aren't supported anyways") to avoid these problems?
Florian
Just a side-note: the same problem is observed in nvidia-dkms[1] AUR package with respect to its dependency on nvidia-utils[2] official package. I've been solving it with `pacman -Ud`, but this is clearly inconvenient.
[1]: https://aur.archlinux.org/packages/nvidia-dkms [2]: https://www.archlinux.org/packages/extra/x86_64/nvidia-utils
Regards,
On 06/08, Florian Bruhin wrote:
Now obviously I have to depend on vim-runtime, and I currently I have the version number pinned (just like the vim package).
Why would you have to depend on it? Either include it in the package or build a split package yourself.
Sorry for the rather late answer here :)
* Stefan Husmann stefan-husmann@t-online.de [2014-08-06 19:45:24 +0200]:
I have other issues: Built from AUR, this is not an official Arch Linux package, so you should use
--with-compiledby="$PACKAGER" instead of --with-compiledby='Arch Linux'
(users who do not set PACKAGER in their makepkg.conf will get an empty string, but this is their fault)
Thanks, fixed.
* Johannes Löthberg johannes@kyriasis.com [2014-08-06 23:39:29 +0200]:
On 06/08, Daniel Micay wrote:
It's necessary to choose between python2 and python3 support.
IIRC both can be compiled in, but only one can be used at runtime
Hmm, *compiling* it with both flags works, but not sure what happens at runtime then? Arch seems to provide a gvim and a gvim-python3 package, and I suspect there is some reason for that.
I'll ask the gvim-maintainer, I'd guess he knows more :)
* Johannes Löthberg johannes@kyriasis.com [2014-08-06 16:14:26 +0200]:
On 06/08, Florian Bruhin wrote:
Now obviously I have to depend on vim-runtime, and I currently I have the version number pinned (just like the vim package).
Why would you have to depend on it? Either include it in the package or build a split package yourself.
That is a good point. Ended up including it, and adding it to provides/conflicts.
Thanks for all your help!
Florian
On 19/08, Florian Bruhin wrote:
Hmm, *compiling* it with both flags works, but not sure what happens at runtime then? Arch seems to provide a gvim and a gvim-python3 package, and I suspect there is some reason for that.
I'll ask the gvim-maintainer, I'd guess he knows more :)
I think that it's supposed to work fine to use one of them, but it'll segfault if you try to use both py2 and py3 at the same time.
* Johannes Löthberg johannes@kyriasis.com [2014-08-19 19:34:14 +0200]:
On 19/08, Florian Bruhin wrote:
Hmm, *compiling* it with both flags works, but not sure what happens at runtime then? Arch seems to provide a gvim and a gvim-python3 package, and I suspect there is some reason for that.
I'll ask the gvim-maintainer, I'd guess he knows more :)
I think that it's supposed to work fine to use one of them, but it'll segfault if you try to use both py2 and py3 at the same time.
It seems to cause trouble when using non-native python libraries:
https://bugs.archlinux.org/task/34397
Also, the maintainer of the vim packages told me the current vim package in [testing] is basically what my vim-full package is, and what used to be vim is now vim-minimal. So it looks like the package won't be needed anymore soon ;)
Florian
On 19/08, Florian Bruhin wrote:
It seems to cause trouble when using non-native python libraries:
Judging from the comments it seems to be a rather simple fix, it would just require rebuilding them.
Also, the maintainer of the vim packages told me the current vim package in [testing] is basically what my vim-full package is, and what used to be vim is now vim-minimal. So it looks like the package won't be needed anymore soon ;)
So now we have vim, vim-python3, gvim, gvim-python3, and vim-minimal. This is starting to feel a bit silly. ;p
On Tue, Aug 19, 2014 at 9:38 PM, Johannes Löthberg johannes@kyriasis.com wrote:
So now we have vim, vim-python3, gvim, gvim-python3, and vim-minimal. This is starting to feel a bit silly. ;p
You forgot about vim-runtime.
On 19/08, Karol Blazewicz wrote:
You forgot about vim-runtime.
Doesn't count since it's the runtime files used by the rest of them.
Am 06.08.2014 um 14:31 schrieb Florian Bruhin:
Hi,
I'm maintaining the vim-full[1] package which is a vim with all the gvim features (Ruby/Lua/Python/Perl/Netbeans) but without GTK/X.
Now obviously I have to depend on vim-runtime, and I currently I have the version number pinned (just like the vim package).
However that makes upgrading vim-runtime difficult, because pacman doesn't know about the vim-full upgrade. A possible solution is to build via `makepkg -d` (ignoring the old vim-runtime version), then upgrading both vim-full and vim-runtime.
Should I just not pin the version at all (as in "partial upgrades aren't supported anyways") to avoid these problems?
Florian
I'd say, regarding pinning keep it as it is.
I have other issues: Built from AUR, this is not an official Arch Linux package, so you should use
--with-compiledby="$PACKAGER" instead of --with-compiledby='Arch Linux'
(users who do not set PACKAGER in their makepkg.conf will get an empty string, but this is their fault)
And: If this is named -full, it should be full, so also python3 should be supported.
Best Regards
Stefan
On 06/08/14 01:45 PM, Stefan Husmann wrote:
Am 06.08.2014 um 14:31 schrieb Florian Bruhin:
Hi,
I'm maintaining the vim-full[1] package which is a vim with all the gvim features (Ruby/Lua/Python/Perl/Netbeans) but without GTK/X.
Now obviously I have to depend on vim-runtime, and I currently I have the version number pinned (just like the vim package).
However that makes upgrading vim-runtime difficult, because pacman doesn't know about the vim-full upgrade. A possible solution is to build via `makepkg -d` (ignoring the old vim-runtime version), then upgrading both vim-full and vim-runtime.
Should I just not pin the version at all (as in "partial upgrades aren't supported anyways") to avoid these problems?
Florian
I'd say, regarding pinning keep it as it is.
I have other issues: Built from AUR, this is not an official Arch Linux package, so you should use
--with-compiledby="$PACKAGER" instead of --with-compiledby='Arch Linux'
(users who do not set PACKAGER in their makepkg.conf will get an empty string, but this is their fault)
And: If this is named -full, it should be full, so also python3 should be supported.
Best Regards
Stefan
It's necessary to choose between python2 and python3 support.
On 06/08, Daniel Micay wrote:
It's necessary to choose between python2 and python3 support.
IIRC both can be compiled in, but only one can be used at runtime
aur-general@lists.archlinux.org