在Linux下安装软件能够引起新手的迷惑，同样也会使有经验的朋友或喜或悲。
下面是在Linux下安装软件我们需要改变的20件事。
1.开源并不仅仅是源代码
“它是开源的，这是源代码。”可能会被忽略。多数用户实际上并不需要源代码，他们想要一个二进制文件。开发者应该提前将他们程序打包，确实需要鼓励开发者这样做。
2.如何运行
“我已经安装了Foo，但是如何运行呢?”在相关论坛上没有看到类似提问的恐怕没有几人吧。所有遵循Freedesktop.org 标准的窗口管理器，都会遵循标准XDG 关于菜单入口的桌面文件规定。安装一个图形化程序就不用抱怨了。
3.标准化界面
忘记关于文件包格式的争论吧，它将永远不会发生。我们需要一个标准软件包图形界面管理器，可以安装所有的软件包。设想一下，Synaptic在Ubuntu和 Fedora上运行，知道是采用Debs包还是RPMs软件包格式，那该多好啊。
4.更容易地添加软件仓库repositories
添加repositories，经常是从浏览器复制粘贴很长、很神秘的文本字符串到终端。一个标准的repository文件会使浏览器启动合适的包管理器将其添加到repository，就是出现一个对话框“are you sure/do you trust this”。
5.更简单地源代码编译
多少程序没有编译器和安装说明呢?很多都有通用的自动生成工具。这很容易呀。那为什么不给用户生成一个Install.sh脚本呢?同时检查一下依赖关系嘛。
6.Autotools = yuck
Autotools 很慢，看起来有一种神秘感。开发者主要使用Autotools。终端用户不应该看到这种东西。
7.降低文件系统杂乱程度
真有必要把文件安装到眼花缭乱的目录中吗?从软件包管理器安装程序是个不错的建议，卸载时候也可以知道把谁给清除了。构建源代码可能在卸载或从系统中移除时不够人性化，尤其是开发者不提供卸载文件时。
8.标准综合包
若是我们不能在单文件包格式上达成协议，标准包管理又从何谈起呢?
9.标准软件包名字
为什么不同的发行版命名同一个软件包会有不同的名字?如果在发行版本之间有一致的命名，解决软件包的依赖关系是不是会更容易些呢?
10.标准软件包拆分
不仅是软件命名需要统一，在每个发行版本里，次软件包也需命名一致。对上游开发者来说，一致性还有一段路要走。
11.去除 -dev软件包
当我们尝试编译源代码时，包含库头文件的-dev 或 -devel软件包会带来无穷的迷惑，比如经常出现像”libfoo not found”这样的信息。当安装GCC或Autotools时，自动安装相关的 -dev 软件包，将会减少我们的痛苦。
12.自动完成源代码软件包的安装
如果每个发行版需要不同的软件包，或许单源软件包能够解决这一情况。但是如果软件包管理器能够自动下载、编译、安装源代码，这不就解决不同包需求了吗?
13.基于浏览器的软件包管理
现在，软件包管理器图形化界面已经很棒了，但是远程安装又得回到命令行下。运行在网络浏览器上的软件包管理器将会使得浏览和升级远程电脑上的软件更加方便。
14.我们需要这么多的软件包吗?
一些项目有源代码，也提供Deb和RPM包文件下载。对每个Ubuntu衍生版本来说，都有自己的软件包，别说SUSE和Fedora的衍生版了。开发者们，真的有必要让可怜的终端用户堕入深渊吗?
15.非单一目录安装
有时，软件在自己的目录里安装的想法会冒出来。嗯，看起来很有吸引力。但对我们用户来说，单击“安装”按钮运行程序，然后在菜单启动就行了。
16.从网页链接到软件管理器
一般来说，当发现想尝试软件所在的一个网址后，接着你开始在软件管理器里面寻找软件包，或冒险使用一个未经发行版本验证的网址的软件包。是不是，从URL启动软件包管理器进而寻找软件包，这样会不会更加方便一些呢?
17.安装后运行
如果安装一份非后台运行的软件，有可能一安装完成，就运行它。要是当安装完成后你喜爱的软件包管理器出现一个核对窗口，是不是更加方便?不必从菜单启动，直接单击“安装并运行”，就这么点事儿。
18.确保源代码在包数据库构建
不仅是从源代码安装有点痛苦，其实，包管理器也不知道你究竟已经安装了什么，所以依赖总是出现缺失，解决不好。要是有一个包管理器，能够从源码包构建，不仅缓解安装的痛苦，也能让我们知道安装了什么。
19.非全包软件包
应用程序和库文件分成单独的包，引起了依赖和其他的问题，但是这被大多数软件包管理器所有效解决。我们也可以通过窗口把所有的东西放在一个包里，这就意味着把分散在文件系统里不同版本的相同库文件聚合到了一起。
20.清除旧的依赖
当你安装软件时，它的依赖也被安装上了。但是当你移除软件包时，这些依赖还呆在系统里，逐渐填满你的硬盘。软件包管理器不仅应该移除不需要的依赖，还应该随时清理系统。
【编辑推荐】
