再吐槽 linux 的版本依赖

今天早上，由于维护docker环境，要安装一个叫Image magick的图片处理工具，这家伙最新版本为6.9.1-6，在安装它之前需要先装delegates，即类似的第三方处理工具，由它去处理png，jpeg等等的啥东西。
就是这一堆东西： http://www.imagemagick.org/download/delegates/

在这个Image magick上花了接近大半天的时间，主要是configure时死活认不出libpng，但实际上已经装完了。
后来实在没办法，硬是换回了旧版本6.9.1-1完事。

有时候，我会想，这些源代码编译软件的存在，就是为了折磨我们吗？这版本依赖的存在，相比windows和mac的一个包搞定的，简直是坑爹得不行。

遇到这样一种源代码安装，并且版本依赖非常强的软件，你们的看法是怎样的？

PS：曾经遇到过一个需要源码编译的软件，它依赖的软件，相关0.0.1都编不过，从那个时候开始，遇到需要编译安装的软件，我就觉得好日子好像又到头了。
PS2：不要说apt-get和yum哈，那两个家伙确实不错，但问题是很多源代码安装的软件不在那里面啊。

lvvj

2015-06-25 09:56:00 +08:00

本以为docker的出现能减轻运维身上的许多压力，不过看讨论…看来以后不能只玩apt了，不然毕业找不到工作啦，2333

cxshun

2015-06-25 10:18:01 +08:00

@neoblackcap 不是，我不是指一定要知道原因，而是怎么去排除问题，不可能一出问题就换版本的啊。所以是否需要换版本这个考虑上还是蛮困难的。
比如windows出问题的时候，我们不是一开始就想着换版本，而是先找问题，看是不是自己的问题嘛，如果不是自己的问题，再考虑换系统或重装。所以在编译这块，我会想，找不到那个libpng会不会是自己装的有问题，所以就一直找，最后没办法，猜想可能是版本问题才换的，原因什么的不重要（因为那个东西不是自己写的），最重要是解决问题嘛。
@lvvj docker里面就是linux哈，也是可以apt的啊。
@feikaras 好吧，看来要去学习下了
@jackieyang51 还有这么高级的东西，赶紧瞧瞧去。
@LeoQ 这种不依赖特定版本的还好，要是依赖某一个特定版本的so那才是坑爹，别人改个名字就只能杯具了。
@lirau 同意，看来要去学习看看make相关的东西。但遇到这种版本问题，需要自己去查找会比较耗时哈。
@lilydjwg 貌似当时找不到，如果所有开源软件都这么规范那就好了。
@cbsw 这个依赖倒是明白，所以我在后面说了，把所有依赖打成一个包是最好的，类似windows的msi和osx的pkg或app，不说另外两个多好，但起码解决了部分依赖问题。
好吧，大家都在安利arch，我要去试下了。
@zhengkai 我把debian里面跟jpeg和png相关的lib装了个遍，dev和非dev全装了，都不行啊，google大半天，也没人有同样的问题，而且大家都用比较老的版本，哭。如果装完OK，那就不用大半天时间啦。
@southwolf 然后呢？只能恢复了吗？好悲伤的故事啊。
@stevegy 对的，就是png那个delegate找不到，实际上就是libpng那些依赖找不到，但已经装好的。

Linusyeung

2015-06-25 10:42:06 +08:00

从来不自己编译…

就像
@LeoQ 的精力，一般人耗不起吧。

ctexlive

2015-06-25 11:43:26 +08:00

根据lz的情况，如果你确认Image magick需要最新的版本，而debian源里的旧版本不足你使用，那么你有好几种方式：
1.如果你不打算自己从头编译（像你情况最好避免自己编译，因为你没有能力解决编译依赖）．最好选一个有最新版Image magick源的linux发行版．如ubuntu的ppa源，archlinux(一般官方源里就足够新）．
2.如果你非要源代码开始编译，请先学会如何创建一个独立的环境进行编译.源代码编译windows下和linux下没有本质区别，通常可能linux下源代码编译更方便．不信你去win下自己编译Image magick试试．别告诉我win下一个包解决，那是人家帮你编译好了，你偷懒了而已．linux下同样有编译好的，只是你自己不会用或者不想用而已．比如im的官方就提供了unix的二进制版．
http://www.imagemagick.org/script/binary-releases.php#unix
这个地址里提供了最新版的Redhat / CentOS 5.11的rpm包， cygwin，mingw包．
在官网里再转下就能找到非rpm系列的通用linux二进制包ImageMagick-x86_64-pc-linux-gnu.tar.gz
http://www.imagemagick.org/download/binaries/
你只要解压，根据说明设置下环境变量就能使用．真不知道lz到底在网站上干了些什么．

ctexlive

2015-06-25 11:44:51 +08:00

@cxshun “实际上就是libpng那些依赖找不到，但已经装好的。”-》你什么信息都没提供，人家怎么帮你解答？

wych

2015-06-25 11:59:44 +08:00

一般的，信任包管理器就好。
有特殊需要要自己维护软件包版本的，请找一个人来维护。不要在这里吐嘈编译的问题，那是基本功不过关。

cxshun

2015-06-25 12:19:48 +08:00

@wych 我没吐槽编译的问题，请看清楚内容，我吐槽的只是版本的问题。编译我可以搞定，而且整个编译一点问题都没有，只是使用的时候出问题罢了。而且编译的问题，我自己有能力可以解决，解决不了的，我可以google，总之都可以找到办法解决。
@ctexlive 我不需要大家帮忙解答编译问题，谢谢。同时请注意，我并不是在求助，让大家帮忙解决这个软件编译的问题。我只是问大家遇到这些版本依赖比较严重的，但同时需要自己编译的软件是怎么解决的。大家一起讨论而已。
@Linusyeung 是啊，我有能力可以去解决，但每个软件都这样花费大把时间，简直是伤不起啊。

MntCw

2015-06-25 12:31:47 +08:00

linux中发现的错误都是用户使用不当造成的，也是醉了。
linux目前只能是活在Geek用户群里了。

LeoQ

2015-06-25 12:46:11 +08:00

@lilydjwg 可选依赖，是的，包括mp3, alsa在内的都被认为是可选依赖，可以生成makefile 如果config报错是makefile是不会生成的。

raptor

2015-06-25 12:58:05 +08:00

@likuku 对，和基本系统隔离很重要。当然现在Linux有Docker

wych

2015-06-25 13:22:29 +08:00

@cxshun 不冲突啊，如果所有的依赖源码都放在一起，只要基础包在任何人都可以./configure && make && make install. 复杂的地方就是这种版本依赖的问题，我的意思就是处理这种问题的方法就那么集中：
1. 用跟进比较快的发行版，比如arch，线上用debian也可以，一般debian的最新版里软件包版本也够用了。
2. 找人/自己维护一个仓库，在一个地方把包编译好然后放到各处安装。

我吐嘈的是这句话「有时候，我会想，这些源代码编译软件的存在，就是为了折磨我们吗？这版本依赖的存在，相比windows和mac的一个包搞定的，简直是坑爹得不行。」

你在windows下和mac下去编译安装的时候，也会碰到相同的版本依赖的问题，解决起来一样的痛苦。而你所说的一个包搞定，对应的也就是Linux里的包管理器，只不过可能有些包windows/mac有人打好了包，你可以直接用，而在Linux里面，每个发行版都有自己跟进新版本的规则，导致你找不到最新的打好了的包，这时候就需要动手解决，而在解决的时候碰到了问题就好好说问题，这种抱怨是没有帮助的。

针对这个编译的问题，新版本的不认libpng，应该去看config.log，如果要需求帮助，应该把这些错误贴出来，补充好上下文，让大家一起看。

ctexlive

2015-06-25 13:29:28 +08:00

@cxshun “我只是问大家遇到这些版本依赖比较严重的，但同时需要自己编译的软件是怎么解决的。大家一起讨论而已。 ”-》没人故意教你，这里只是针对你提出的问题的举例，而事实上你确实解决的不好．．．我们对你的编译解决能力只能通过你的语言来判断，也无意故意贬低你．从你的描述看你，你一方面拿“linux下的编译依赖”和“这版本依赖的存在，相比windows和mac的一个包搞定的，简直是坑爹得不行。”来比较，不是一个层面的东西，本身不觉得很奇怪么？当然，你如果只是拿出“源代码编译”是否有很多坑，那你至少在问题描述里体现的观点就有问题．要比就要用对等的对象来比．编译的依赖，无非就是自动解决依赖和手动解决依赖．自动解决依赖以及描述过，我实证看不出win和mac哪里解决的更好．手动解决依赖三者都一样．况且你如果用apt，pacman等自动依赖解决系统，显然会更方便．

“相关0.0.1都编不过，从那个时候开始，遇到需要编译安装的软件，我就觉得好日子好像又到头了。"..事实上，你所谓的编译不过，很可能就是代码本身质量不好造成．而且你没提供任何编译的出错信息，大家根本无从判断到底是”代码本身问题“，还是”依赖本身“问题，或者其他问题．讨论问题当然要就事论事，针对你提出的案例讨论．

izoabr

2015-06-25 13:49:53 +08:00

那gentoo。。。矮油···

cxshun

2015-06-25 14:08:11 +08:00

@ctexlive 多谢，确实，源代码和win、mac上面的包不是一个东西。我描述的不大清楚，见笑了。但提出这个问题的重点是在后面，如果大家遇到一些自己要用的东西，但由于遇到一些依赖的问题，是绕过呢，还是去解决（解决意味着要花费比较多的时间）。
@wych 确实，我的对比不大合理。多谢指正。

wych

2015-06-25 17:28:42 +08:00

@cxshun 我的做法一般是，如果程序必须用某个版本（有时候是旧的版本），那么我会尽量完成一次编译安装，然后按照发行版本的规则打包，放到自己维护的repo里面。如果不是，在程序里可以绕过，那么就绕过好了。

benjiam

2015-06-25 17:34:24 +08:00

我觉得楼主说了一个非常重要的问题。

其实无论是否源码编译用yum 甚至 apt-get 都没有完全解决这个问题。

windows 里面也有这个问题，虽然很多年来ms 就号称解决了这个问题，但是我们知道其实没有

一项项的看

1 源码编译，
基本是一个彻底的解决方法。唯一要看的就是编译的时候一堆堆一堆的depends.

depends 问题可以解决，但是更关键是编译参数的设置，比如 nginx 的可配置的参数， php 的可配置参数对于一个使用者，如何详细辨别需要设置的编译参数我觉得很难。看configure --help... 其实和看汽车说明书差不多，有多少人是只会开，连换个轮胎都不会。你知道php 这么多配置参数应该如何组合才是最正确的吗？我不知道，我只能选几个我需要的模块然后编译一下

2 yum apt
是比较好的方案，但是主要的问题有2个，第一个没有该包的源第二个如果有冲突问题那就很难，我反正没办法

第一个比如我们需要在ubuntu12.04 上使用比较新的软件 libboost 但是最新的包只会发布在14.04, 我的选择基本上就只有自己拖source, 在ubuntu 12.04 重新打包，重新打包带来的问题非常的多，解决起来非常的难，做过的都知道
第二本质还是依赖，在yum 和apt 里面遇到一次2个包有冲突无法共存，你必须做出一个2选1，想利用yum 让他们共存基本不可能。
第三还有个问题就是依赖太大了，装一个软件需要装a, 结果a要求升级glibc, 然后一下子就是2G的新软件包，一次性升级了几百个软件，对于大型在线系统，这样的解决方案实战不能接受。

3 windows
对于这个问题解决的相对比较好，从windows98 上拿个游戏copy 到winxp win7 上基本都能运行起来，不会出现什么问题。但是早期的dll hell，也真是让人欲哭无泪，但是windows 完全解决这些问题了吗？ Visual Studio 2010 Redistribute Package 这个包大家很熟悉吧。我的qq 在每次重装以后就必须重新安装，装Redistribute Package 也不行。但是对于大多数情况，我觉得做得都很对。

4 gentoo ？
简单玩过LFS gentoo 不评价

我心中理想的解决办法：去掉动态编译，只是用静态编译类似golang, 虽然动态编译减少了体积和运行时大小，提高了运行速度，但是带来的问题太多了。作为一个产品最基本的一个要素快速发布因为这个原因被大大的削弱。在这个CPU memory disk 都有富裕的时代，应该使用静态编译 copy paste 进行发布！