Re: [aur-general] Pinning dependency versions in PKGBUILDs?
Sorry for the rather late answer here :) * Stefan Husmann stefan-husm...@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 johan...@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 johan...@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 -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpsNxqZiVJNz.pgp Description: PGP signature
Re: [aur-general] Pinning dependency versions in PKGBUILDs?
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 pgpUNaETGzcs1.pgp Description: PGP signature
Re: [aur-general] Pinning dependency versions in PKGBUILDs?
* Johannes Löthberg johan...@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 -- http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpGuacw4qQrb.pgp Description: PGP signature
Re: [aur-general] Pinning dependency versions in PKGBUILDs?
On 19/08, Florian Bruhin wrote: It seems to cause trouble when using non-native python libraries: https://bugs.archlinux.org/task/34397 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 pgpsLWSWUKHSs.pgp Description: PGP signature
Re: [aur-general] Pinning dependency versions in PKGBUILDs?
On Tue, Aug 19, 2014 at 9:38 PM, Johannes Löthberg johan...@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.
Re: [aur-general] Pinning dependency versions in PKGBUILDs?
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 pgpiLbbxfDQvr.pgp Description: PGP signature
[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 | m...@the-compiler.org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ pgpDTZCh1jcD2.pgp Description: PGP signature
Re: [aur-general] Pinning dependency versions in PKGBUILDs?
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 [1] https://aur.archlinux.org/packages/vim-full/ 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 / signature.asc Description: This is a digitally signed message part.
Re: [aur-general] Pinning dependency versions in PKGBUILDs?
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 pgpmRWKKe2cOQ.pgp Description: PGP signature
Re: [aur-general] Pinning dependency versions in PKGBUILDs?
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 [1] https://aur.archlinux.org/packages/vim-full/ 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
Re: [aur-general] Pinning dependency versions in PKGBUILDs?
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 [1] https://aur.archlinux.org/packages/vim-full/ 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. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Pinning dependency versions in PKGBUILDs?
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 pgpYcC7GQjAeo.pgp Description: PGP signature
