[aur-general] Pinning dependency versions in PKGBUILDs?
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/ -- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
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, -- Ivan Shapovalov / intelfx /
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. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
Sorry for the rather late answer here :)
* Stefan Husmann
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
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
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 -- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
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. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
* Johannes Löthberg
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 -- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
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 -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
On Tue, Aug 19, 2014 at 9:38 PM, Johannes Löthberg
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. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
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 -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
participants (6)
-
Daniel Micay
-
Florian Bruhin
-
Ivan Shapovalov
-
Johannes Löthberg
-
Karol Blazewicz
-
Stefan Husmann