Re: [arch-general] [arch-dev-public] status of vi/vim in testing
On Wed, Jun 17, 2009 at 3:25 PM, Tobias Powalowski <t.powa@gmx.de> wrote:
Tobias Powalowski wrote:
Hi just wondered, what is the status of vi/vim in testing, this one blocks archboot from moving to extra, is there any progress of moving it to extra/core?
On this topic, both vi an vim are currently in base. Is this a mistake? I find the new (n)vi unusable and and removed it and make vi a symlink to vim. Although the current vim is bigger, I would not object to removing vi and adding a symlink from vi to vim-normal...
Allan It's a whole mess, which needs to be cleaned. First should be decided in which direction this should go.
Am Mittwoch 17 Juni 2009 schrieb Allan McRae: personally i hate this nvi, it's so restricted. greetings tpowa <tpowa@archlinux.org>
I was about to send an email to Tobias the other day but i could get my script to work so i removed the draft i had saved. IMO this packaging scheme sucks for both vi and vim. I was looking at the CRUX vim script and if a package like that can be achieved IMO its the best solution. Current situation (in testing) vim depends only on perl (optdepend) so this package might as well be in [core] instead of [extra] . That means it would need signoffs for it & gvim as well. I would be in favour of building a vim package in [core] that includes both a vi & vim binary, like CRUX seems to do it. http://crux.nu/ports/crux-2.5/core/vim/Pkgfile I just couldnt get my script to build so hadnt suggested it so far. I wonder if thats possible. The reasons the previous scheme changed was mainly because people complained that vi isnt really vi but vim, so this scenario would cover it Sorry for interefering. -- Greg
On Wed, Jun 17, 2009 at 3:36 PM, Grigorios Bouzakis <grbzks@gmail.com>wrote:
On Wed, Jun 17, 2009 at 3:25 PM, Tobias Powalowski <t.powa@gmx.de> wrote:
Tobias Powalowski wrote:
Hi just wondered, what is the status of vi/vim in testing, this one blocks archboot from moving to extra, is there any progress of moving it to extra/core?
On this topic, both vi an vim are currently in base. Is this a mistake? I find the new (n)vi unusable and and removed it and make vi a symlink to vim. Although the current vim is bigger, I would not object to removing vi and adding a symlink from vi to vim-normal...
Allan It's a whole mess, which needs to be cleaned. First should be decided in which direction this should go.
Am Mittwoch 17 Juni 2009 schrieb Allan McRae: personally i hate this nvi, it's so restricted. greetings tpowa <tpowa@archlinux.org>
I was about to send an email to Tobias the other day but i could get my script to work so i removed the draft i had saved. IMO this packaging scheme sucks for both vi and vim. I was looking at the CRUX vim script and if a package like that can be achieved IMO its the best solution. Current situation (in testing) vim depends only on perl (optdepend) so this package might as well be in [core] instead of [extra] . That means it would need signoffs for it & gvim as well. I would be in favour of building a vim package in [core] that includes both a vi & vim binary, like CRUX seems to do it. http://crux.nu/ports/crux-2.5/core/vim/Pkgfile I just couldnt get my script to build so hadnt suggested it so far. I wonder if thats possible. The reasons the previous scheme changed was mainly because people complained that vi isnt really vi but vim, so this scenario would cover it Sorry for interefering.
-- Greg
Heres the gvim script too, all those are bundled together: http://crux.nu/ports/crux-2.5/opt/gvim/Pkgfile -- Greg
On Wed, Jun 17, 2009 at 8:36 AM, Grigorios Bouzakis<grbzks@gmail.com> wrote:
I would be in favour of building a vim package in [core] that includes both a vi & vim binary
or you mean symlinking vi to vim... which is fine. the problem is not so much 'really vi but vim' but more that the whole package was/is (testing not included) really really screwed up. if busybox was in arch by default I'd suggest symlinking to that and let people change the symlink if they need something more powerful, esp since busybox can provide so many apps. -- Caleb Cushing http://xenoterracide.blogspot.com
On Wed, Jun 17, 2009 at 6:01 PM, Caleb Cushing <xenoterracide@gmail.com>wrote:
On Wed, Jun 17, 2009 at 8:36 AM, Grigorios Bouzakis<grbzks@gmail.com> wrote:
I would be in favour of building a vim package in [core] that includes both a vi & vim binary
or you mean symlinking vi to vim... which is fine. the problem is not so much 'really vi but vim' but more that the whole package was/is (testing not included) really really screwed up. if busybox was in arch by default I'd suggest symlinking to that and let people change the symlink if they need something more powerful, esp since busybox can provide so many apps.
-- Caleb Cushing
No i dont mean symlinking vi to vim. Thats not an option. See http://bugs.archlinux.org/task/13239#comment39968 & downwards. I mean building both in the same PKGBUILD. See the CRUX Pkgfile i posted previously I think it does exactly that. -- Greg
On Wed, Jun 17, 2009 at 11:11, Grigorios Bouzakis<grbzks@gmail.com> wrote:
No i dont mean symlinking vi to vim. Thats not an option. See http://bugs.archlinux.org/task/13239#comment39968 & downwards. I mean building both in the same PKGBUILD. See the CRUX Pkgfile i posted previously I think it does exactly that. -- Greg
Since having vi is required by the POSIX standards, wouldn't a bundled vi+vim make perl required? Or is it an actual optdepend for vim? (I'm not at my home box at the moment to check)
On Wed, Jun 17, 2009 at 6:15 PM, Daenyth Blank<daenyth+arch@gmail.com> wrote:
On Wed, Jun 17, 2009 at 11:11, Grigorios Bouzakis<grbzks@gmail.com> wrote:
No i dont mean symlinking vi to vim. Thats not an option. See http://bugs.archlinux.org/task/13239#comment39968 & downwards. I mean building both in the same PKGBUILD. See the CRUX Pkgfile i posted previously I think it does exactly that. -- Greg
Since having vi is required by the POSIX standards, wouldn't a bundled vi+vim make perl required? Or is it an actual optdepend for vim? (I'm not at my home box at the moment to check)
What do the POSIX standards say, having a vi named package, or binary? I think its the second. Vim in testing has no X capabilities and only the perl interpeted enabled. Still perl is only an optional dependency. What if perl was an actual dependency. Its already in base. I dare not to imagine a system not having perl installed. Anyway i dont know if my suggestion actually works as i imagine. -- Greg
participants (3)
-
Caleb Cushing
-
Daenyth Blank
-
Grigorios Bouzakis