On Nov 28, 2013 10:50 PM, "Gary Johnson" <garyjohn@spocom.com> wrote:
>
> On 2013-11-28, Nikolay Pavlov wrote:
>
> > Also using "make install" is considered a bad practice for any
> > distribution. It does not do something like rendering vim unusable,
> > but maintaining jobs (like updating software on machine) will
> > become such a pain in ass if you have packages installed like this.
>
> "make install" is pretty standard practice and this is the first I've
> heard that it is considered bad. It has always worked fine for me.
> The only problem I can think of is that it is not always easy to
> uninstall programs, but I never do that.
Since you do not know which package specific file belongs to you cannot update without risking leaving old files. What if some plugin in vim distribution got renamed? Two "make install" and you have two versions of plugin, likely conflicting.
You do not get whatever advantages your distribution provides when updating configuration in /etc. "make install" will simply overwrite whatever changes you have made.
You do not get proper dependency handling: if ncurses got updated and vim relies on older version you will have to recompile (without system administrator who will compile vim for you only source-based distributions will be able to workaround this completely automatically).
You will have to backup more data to restore system from complete / destruction: normally it is /etc and list of installed packages, with "make install" it is full disk image (may not be a problem as restoring from full image is faster and speed had priority over size when designing how to backup).
You will be unable to check whether installed vim files were damaged after a crash.
You see, it is not something which will hit you in day-to-day use. But it makes emergencies easier to appear and harder to recover. There is also a known proverb: "A single 'make install' turns any distribution into Slackware" (it may be local to Russia though).
>
> What do you recommend instead?
It is completely distribution-specific. I would write ebuild in this case (Gentoo-specific) or leave vim not installed and running from mercurial repository where it was build (assuming I am the only user on the machine; otherwise *only* ebuild).
Note that the solution will most likely use "make install" on its own. But there is a *very* big difference: it will install to some location where there is nothing else but vim files and copy files out of there, doing necessary job (e.g. computing checksums and recording which package files belong to) (with a possible intermediate state of creating binary packages). In Gentoo it even uses sandbox to make sure ebuild will not ever put or touch files anywhere but in /var/tmp/portage/(category)/(name)-(version).
>
> Regards,
> Gary
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment