[gentoo-dev] vim and gvim package split

[gentoo-dev] vim and gvim package split

[Alessandro DE LAURENZIS]

I guess this is an already debated topic, but I only found this very
old thread on the subject:

http://article.gmane.org/gmane.linux.gentoo.devel/4328

which contains the original communication of the ebuild split and some
discussions and observations that probably are no more applicable.

I'm absolutely convinced that one of the gentoo strengths is the USE
variable handling compile time options, so I do not see any points to
split packages when not absolutely needed.

In case of vim-core/vim/gvim (and vim-qt?), I cannot understand
the reason... Are still there advantages in doing so?

Thanks for your time

-- 
Alessandro DE LAURENZIS
[mailto:just22.adl@gmail.com]
LinkedIn: http://it.linkedin.com/in/delaurenzis

Re: [gentoo-dev] vim and gvim package split

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

On 1 November 2013 11:02, Alessandro DE LAURENZIS <just22.adl@gmail.com>wrote:

>
> In case of vim-core/vim/gvim (and vim-qt?), I cannot understand
> the reason... Are still there advantages in doing so?


Useflags have their perks for giving variations on behaviour, but having 3
effective packages in one, governed by useflags, means you'll have 3 much
more tightly coupled packages, and the code will be much messier with
useflag conditionals to pull dependencies.

If you imagine useflags like "if" statements, and ebuilds like independent
classes where "dependencies" are a kind of inheritance, you may find
theres' reasonable benefits for the maintenance side

e.g.: people checking reverse deps for QT don't have to worry about changes
in QT breaking vim and gvim because those packages are independent of QT
interaction

Fixes that need to go in to make building vs QT mean only the qvim ebuild
gets updated and the rest are fine as-is.

The only real downside is if you're building all 3 {q,g,}vim there's a
little compile time overhead as a result ( Though I'm not sure what the
difference is in real terms )

But by having them seperate, we enjoy a more robust installation,
especially for people who only want one of the 3, then they're not
needlessly burdened by logic to handle things they're not using, which
could break.

Not to mention you have to deal with overheads introduced by having to work
out the equivalent of all three of the above having vastly different
useflags and making useflags conditional upon each other as a result to
codify the same behaviour, again, further raising the odds that a
situtation will arise where things break and the dependencies/use flags
are  a mess.

-- 
Kent

[-- Attachment #2: Type: text/html, Size: 2427 bytes --]

[gentoo-dev] Re: vim and gvim package split

[Alessandro DE LAURENZIS]

Kent Fredric <kentfredric <at> gmail.com> writes:

> Useflags have their perks for giving variations on behaviour, but having 3
> effective packages in one, governed by useflags, means you'll have 3 much
> more tightly coupled packages, and the code will be much messier with
> useflag conditionals to pull dependencies.
> 
> If you imagine useflags like "if" statements, and ebuilds like independent
> classes where "dependencies" are a kind of inheritance, you may find theres'
> reasonable benefits for the maintenance side  e.g.: people checking reverse
> deps for QT don't have to worry about changes in QT breaking vim and gvim
> because those packages are independent of QT interaction 
> 
> 
> Fixes that need to go in to make building vs QT mean only the qvim ebuild
> gets updated and the rest are fine as-is.
> 
> The only real downside is if you're building all 3 {q,g,}vim there's a
> little compile time overhead as a result ( Though I'm not sure what the
> difference is in real terms )
> 
> But by having them seperate, we enjoy a more robust installation,
> especially for people who only want one of the 3, then they're not
> needlessly burdened by logic to handle things they're not using, which
> could break.
> 
> Not to mention you have to deal with overheads introduced by having to
> work out the equivalent of all three of the above having vastly different
> useflags and making useflags conditional upon each other as a result to
> codify the same behaviour, again, further raising the odds that a situtation
> will arise where things break and the dependencies/use flags are  a mess.

Kent,

all your argumentations make sense, but actually only apply to vim-qt, which
isn't in fact in the vim main tree.

In other words: it's normal that vim and vim-qt are two different packages,
but gvim is just vim with the GUI interface (neither an add-on nor a different
project); playing with USE flags in /etc/portage/package.use should give easy
access to all the possible options:

- only vim ("-gtk");
- gvim ("gtk");
- qvim ("-gtk" for vim and vim-qt as package, having vim as dependency);
- or even both ("gtk" for vim and vim-qt).

What's wrong or complex (from a mantainer perspective) with this?

Thanks for your comments

Re: [gentoo-dev] Re: vim and gvim package split

[Steev Klimaszewski]

On Fri, 2013-11-01 at 16:52 +0000, Alessandro DE LAURENZIS wrote:
> Kent Fredric <kentfredric <at> gmail.com> writes:
> 
> > Useflags have their perks for giving variations on behaviour, but having 3
> > effective packages in one, governed by useflags, means you'll have 3 much
> > more tightly coupled packages, and the code will be much messier with
> > useflag conditionals to pull dependencies.
> > 
> > If you imagine useflags like "if" statements, and ebuilds like independent
> > classes where "dependencies" are a kind of inheritance, you may find theres'
> > reasonable benefits for the maintenance side  e.g.: people checking reverse
> > deps for QT don't have to worry about changes in QT breaking vim and gvim
> > because those packages are independent of QT interaction 
> > 
> > 
> > Fixes that need to go in to make building vs QT mean only the qvim ebuild
> > gets updated and the rest are fine as-is.
> > 
> > The only real downside is if you're building all 3 {q,g,}vim there's a
> > little compile time overhead as a result ( Though I'm not sure what the
> > difference is in real terms )
> > 
> > But by having them seperate, we enjoy a more robust installation,
> > especially for people who only want one of the 3, then they're not
> > needlessly burdened by logic to handle things they're not using, which
> > could break.
> > 
> > Not to mention you have to deal with overheads introduced by having to
> > work out the equivalent of all three of the above having vastly different
> > useflags and making useflags conditional upon each other as a result to
> > codify the same behaviour, again, further raising the odds that a situtation
> > will arise where things break and the dependencies/use flags are  a mess.
> 
> Kent,
> 
> all your argumentations make sense, but actually only apply to vim-qt, which
> isn't in fact in the vim main tree.
> 
> In other words: it's normal that vim and vim-qt are two different packages,
> but gvim is just vim with the GUI interface (neither an add-on nor a different
> project); playing with USE flags in /etc/portage/package.use should give easy
> access to all the possible options:
> 
> - only vim ("-gtk");
> - gvim ("gtk");
> - qvim ("-gtk" for vim and vim-qt as package, having vim as dependency);
> - or even both ("gtk" for vim and vim-qt).
> 
> What's wrong or complex (from a mantainer perspective) with this?
> 
> Thanks for your comments
> 
> 
> 
For binary package use, it's nice, as you may want to only install vim
on one machine, and gvim on a different one, but if you use the same
binhost that means you have to build vim rather than use the binary
packages.

Re: [gentoo-dev] vim and gvim package split

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

On Thu, 31 Oct 2013 23:02:12 +0100
Alessandro DE LAURENZIS <just22.adl@gmail.com> wrote:
> I guess this is an already debated topic, but I only found this very
> old thread on the subject:
> 
> http://article.gmane.org/gmane.linux.gentoo.devel/4328
> 
> which contains the original communication of the ebuild split and some
> discussions and observations that probably are no more applicable.
> 
> I'm absolutely convinced that one of the gentoo strengths is the USE
> variable handling compile time options, so I do not see any points to
> split packages when not absolutely needed.
> 
> In case of vim-core/vim/gvim (and vim-qt?), I cannot understand
> the reason... Are still there advantages in doing so?

First, if your Vim breaks due to you upgrading insufficiently-slotted
libraries (which it will), you're screwed. There's a lot of value in
having a small vim that doesn't link to things, and a big gvim that
does.

Secondly, Vim's build system means you'd have to build the whole thing
twice anyway if you wanted to do a vim that doesn't link to Gtk+ and a
gVim that does in the same ebuild.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] vim and gvim package split

[Alessandro DE LAURENZIS]

On Fri, 1 Nov 2013 18:23:48 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> First, if your Vim breaks due to you upgrading insufficiently-slotted
> libraries (which it will), you're screwed. There's a lot of value in
> having a small vim that doesn't link to things, and a big gvim that
> does.
> 
> Secondly, Vim's build system means you'd have to build the whole thing
> twice anyway if you wanted to do a vim that doesn't link to Gtk+ and a
> gVim that does in the same ebuild.
> 

Thanks Ciaran for this very clear explaination, I got your points.
Actually, I always though to vim as the system's "non-minimal" vi flavor,
reserving the "minimal" role to vi from busybox, but I can agree that a
minimal vim (linking as less things as possible) which coexists with a
full-featured gvim is a reasonable solution.

So the split makes sense.

Thank you again.


-- 
Alessandro DE LAURENZIS
[mailto:just22.adl@gmail.com]
LinkedIn: http://it.linkedin.com/in/delaurenzis