redhat系列linux系统的yum，有时会出现错误的依赖，用linux早期，遇到该类问题简直是束手无策，无奈之下会在yum的“教唆“下使用“–skip-broken”参数，有时确实可以解决问题，但有时的后果，可以把系统玩儿坏，下次启动无法启动，或出现其它莫名其妙的问题。
列一个典型的错误依赖消息如下：
--& 正在处理依赖关系 /usr/sbin/ldconfig，它被软件包 libva1-1.3.1-11.el7.x86_64 需要
--& 正在处理依赖关系 /usr/sbin/ldconfig，它被软件包 libmad0-0.15.1b-4.el7.x86_64 需要
--& 正在处理依赖关系 /usr/sbin/ldconfig，它被软件包 librtmp0-2.3-1.el7.x86_64 需要
--& 正在处理依赖关系 /usr/sbin/ldconfig，它被软件包 libx264_142-0.142-20_5.el7.x86_64 需要
--& 正在处理依赖关系 /usr/sbin/ldconfig，它被软件包 libxvidcore4-1.3.2-15.el7.x86_64 需要
错误：软件包：libmad0-0.15.1b-4.el7.x86_64 (@atrpms)
需要：/usr/sbin/ldconfig
正在删除: glibc-2.17-55.el7_0.1.i686 (@updates)
更新，由: glibc-2.17-55.el7_0.3.i686 (updates)
错误：软件包：librtmp0-2.3-1.el7.x86_64 (@atrpms)
需要：/usr/sbin/ldconfig
正在删除: glibc-2.17-55.el7_0.1.i686 (@updates)
更新，由: glibc-2.17-55.el7_0.3.i686 (updates)
您可以尝试添加 --skip-broken 选项来解决该问题
您可以尝试执行：rpm -Va --nofiles --nodigest
看到了最后两行了吧，通常别听信它，小心！
为了优雅的处理类似错误依赖的问题，要搞先了解一下该问题的原因。通常是在自己手动安装了一些非官方rpm包，或使用了多个yum源所致。尤其是升级安装了新版本的包。例如，在centos里为了安装某些软件而使用fedora里的包升级了系统自带的包。
个人经验如下：
先移除/etc/yum.repo.d/下非系统官方的源，备份到其它目录里，处理好问题后还移回来继续用。
yum list 查看系统都有哪些源的包，除了@base @anaconda @updates 之外的，都要留意一下，按“靠谱”程度从低到高逐渐移除。这里的“靠谱程度”，要凭一些经验的。 如本文前面列出错误依赖的这个例子，本人用了好多个源的包，@epel @atrpms
@nux-dextop @google-chrome 等这几个第三方源，epel是很高质量的，google-chrome 只有chrome浏览器，其它几个就是不太靠谱的，先移除它们。
检查yum list列出的包名，是否用了fedora，或非本机架构的等的包（如x64系统下686的包），yum erase移除它们。卸载包时，注意着，别把重要的系统包卸载了。千万别这样带-y 参数据 yum erase
-y，yum erase 卸载某个包时，系统提示会提示都移除哪些包，如果看着不对劲就按 N
最后，你会找到出问题的那个包名，即提示错误依赖的信息
--& 正在处理依赖关系 /usr/sbin/ldconfig，它被软件包 libbluray1-0.4.0-6.el7.x86_64 需要
--& 解决依赖关系完成
错误：软件包：libbluray1-0.4.0-6.el7.x86_64 (@atrpms)
需要：/usr/sbin/ldconfig
正在删除: glibc-2.17-55.el7_0.1.x86_64 (@updates)
更新，由: glibc-2.17-55.el7_0.3.x86_64 (updates)
您可以尝试添加 --skip-broken 选项来解决该问题
您可以尝试执行：rpm -Va --nofiles --nodigest
会类似上面所示，只是少数一两个包，尝试卸载一下看看
[root@fsc ~]# rpm -e libbluray1-0.4.0-6.el7.x86_64
错误：依赖检测失败：
libbluray.so.1()(64bit) 被 (已安裝) gvfs-1.16.4-7.el7.x86_64 需要
libbluray.so.1()(64bit) 被 (已安裝) gvfs-fuse-1.16.4-7.el7.x86_64 需要
libbluray.so.1()(64bit) 被 (已安裝) gvfs-afc-1.16.4-7.el7.x86_64 需要
libbluray.so.1()(64bit) 被 (已安裝) gvfs-gphoto2-1.16.4-7.el7.x86_64 需要
libbluray.so.1()(64bit) 被 (已安裝) gvfs-goa-1.16.4-7.el7.x86_64 需要
libbluray.so.1()(64bit) 被 (已安裝) gvfs-mtp-1.16.4-7.el7.x86_64 需要
libbluray.so.1()(64bit) 被 (已安裝) gvfs-smb-1.16.4-7.el7.x86_64 需要
libbluray.so.1()(64bit) 被 (已安裝) gvfs-afp-1.16.4-7.el7.x86_64 需要
libbluray.so.1()(64bit) 被 (已安裝) gvfs-archive-1.16.4-7.el7.x86_64 需要
libbluray.so.1()(64bit) 被 (已安裝) libbluray-0.4.0-6.el7.x86_64 需要
libbluray1 = 0.4.0-6.el7 被 (已安裝) libbluray-0.4.0-6.el7.x86_64 需要
那查查系统里该包是什么版本吧 rpm -q {包名}
上面例子里，该包是atrpms源的包，比centos源里的包新。回忆时当时为了安装smplayer，装了一系列atrpms的包。而印象中，atrpms源有时会升级centos的包，所以就造成了yum update 升级系统时造成错误依赖。到centos镜像里下载这个rpm包，rpm –force
-Uvh {包文件路径}覆盖安装一下，然后再yum更新试试。
如果没有问题，那就好了。再把yum 源的配置文件移回去，重新yum makecache，然后根据刚才卸载的包的记录，把它们安装上；可参考history 命令的记录.
大概就是这样，写得有点乱。
延伸阅读coded by
有人回复时邮件通知我
赞助商链接博客分类：
转载请注明出处哈:http://yanan0628.iteye.com/blog/2270409
1.maven依赖的几个特性
1.1 依赖范围 -scope标签
maven在构建过程有3套classpath,我们会根据配置依赖的范围 依赖不同的classpath,如下图：
compile：默认是compile,对 编译 测试 运行 都有效
provided:对编译和测试classpath有效，运行的时候不需要加入，例如 jsp 依赖 searvlet api ，比如我们在编译和测试的时候有效但是在运行的时候
容器已经提供servletapi,如果加入会造成冲突
runtime:只在测试和运行时 有效，比较典型的例子 jdbc api，只有在启动代码测试或者运行的时候才会启用
test：只会在测试时有效，比较典型例子 就是junit ，只有再测试的时候 才会启用
1.2 依赖传递
比如我们引入某一个依赖spring-test,依赖传递特性会很方便帮助我们下来它相关的依赖，而不必有时会因为引入jar有问题而烦恼，但是也有弊端，存在一些不必要的依赖，可能会造成冲突。
1.3 依赖排除 -exclusion标签
依赖排除的特性 也是为了解决依赖冲突的一个方法，很方便去除依赖传递过程中不必要的依赖。在下面依赖冲冲突会用到 该标签。
1.4 依赖冲突产生原因
使用maven久了会发现存在依赖冲突的问题,由于依赖的传递特性会引入很多隐式的依赖和现有显示jar版本
所冲突，从而造成版本冲突的问题。要解决这个问题，首先就是要查看pom.xml显式和隐式的依赖类包，
然后通过这个类包树找出我们不想要的依赖类包，手工将其排除在外就可以了。
2.依赖冲突的解决
2.1两个基本原则：
1).短路优先原则
A-&B-&logback-1.0.jar
A-&logback-1.1.jar
2).先声明先优先原则(先解析先引用)
与项目A pom中配置 引用坐标的顺序有关,如果依赖B在C前的话 就优先B，反之...
A-&B-&logback-1.0.jar
A-&C-&logback-1.1.jar
2.2 演示两个原则
1).创建三个maven工程
maven-01,maven-02,maven-03
2).三个工程依赖结构:
maven-01依赖 spring-test,maven-02,maven-03 (maven-02/03需要首先提交本地仓库，maven-01才能找到 ，可以参考寻找构件过程：) ;
maven-02依赖commons-logging-1.1.1;
maven-03工程依赖 commons-logging-1.1.3
3).看下myEclipse或者执行mvn dependency:tree 查看依赖树：
myeclispe:依赖树
4).冲突解决办法：
&dependency&
&groupId&org.springframework&/groupId&
&artifactId&spring-test&/artifactId&
&version&4.2.2.RELEASE&/version&
&!-- 依赖排除 可以排除对commons-logging 的依赖
&exclusions&
&exclusion&
&groupId&commons-logging&/groupId&
&artifactId&commons-logging&/artifactId&
&/exclusion&
&/exclusions&
&/dependency&
&!-- 添加对maven-02依赖 --&
&dependency&
&groupId&com.sohu.train&/groupId&
&artifactId&maven-02&/artifactId&
&version&1.0-SNAPSHORT&/version&
&/dependency&
短路优先原则：
maven-01-&spring-test-&spring-core-&commons-loggings-1.2(依赖深度3)
maven-01-&maven-02-&commons-loggings-1.1.1(依赖深度2)
所以maven01工程依赖的commons-loggings-1.1.1
4.2 pom配置2:
&dependency&
&groupId&org.springframework&/groupId&
&artifactId&spring-test&/artifactId&
&version&4.2.2.RELEASE&/version&
&!-- 依赖排除 --&
&exclusions&
&exclusion&
&groupId&commons-logging&/groupId&
&artifactId&commons-logging&/artifactId&
&/exclusion&
&/exclusions&
&/dependency&
&!-- 添加对maven-03依赖
&dependency&
&groupId&com.sohu.train&/groupId&
&artifactId&maven-03&/artifactId&
&version&0.0.1-SNAPSHOT&/version&
&/dependency&
&!-- 添加对maven-02依赖 --&
&dependency&
&groupId&com.sohu.train&/groupId&
&artifactId&maven-02&/artifactId&
&version&1.0-SNAPSHORT&/version&
&/dependency&
先引用先优先的原则：
maven-01-&spring-test-&spring-core
maven-01-&maven-02-&commons-logging-1.1.1
maven-01-&maven-03-&commons-logging-1.1.3
如果pom先依赖maven-02则 依赖commons-logging-1.1.1 依赖；反之，如果pom先依赖maven-03则 依赖commons-logging-1.1.3 依赖
所有文章：
maven系列文章：
浏览: 74531 次
浏览量：36771
浏览量：16819
浏览量：6521
分享一款代码生成器，拖拽式组件结合流式处理，很容易的访问数据库 ...
请教楼主，maven-aggregate是如何用eclipse ...
好东西，不错，学习了
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'交流 学习 随笔
Maven 依赖范围、依赖传递、排除依赖
回顾下maven构建坐标的构成，如下
看上面的xml片段，会发现一个新东西scope
这个标签的意思就是当前插件依赖的范围
在开发中我们把第三方jar放入到classpath中，就能够调用第三方的类和方法。
maven有3中classpath分别是
上面的xml片段中scope的值为test，也就是说这个构建只存在于测试环境中。
所以scope的值就是控制与三种classpath的关系。
This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases. This scope is not transitive.
This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
import (only available in Maven 2.0.9 or later)
This scope is only supported on a dependency of type pom in the
section. It indicates the dependency to be replaced with the effective list of dependencies in the specified POM’s
section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.
1. compile 默认的范围，编译测试运行都有效。
2. provided 编译和测试时有效，最后是在运行的时候不会被加入。官方举了一个例子。比如在JavaEE web项目中我们需要使用servlet的API，但是呢Tomcat中已经提供这个jar，我们在编译和测试的时候需要使用这个api，但是部署到tomcat的时候，如果还加入servlet构建就会产生冲突，这个时候就可以使用provided。
3. runtime 在测试和运行时有效。
4. test 在测试时有效。
5. system 与本机系统相关联，可移植性差。编译和测试时有效。
6. import 导入的范围，它只在使用dependencyManagement中，表示从其他pom中导入dependecy的配置。
举个import栗子
解释：就是把A中的构建导入到B中。
在正常开发中，我们也会封装maven构建供小伙伴们使用，在我们使用自定义的构建中，那么我们自定义的构建中依赖的构建，也会依赖传递过来。
先建立第一个项目project01
建立第二个项目project02
建立第二个项目project03
我们把project01打包安装到本地仓库中。
clean install
在project02中依赖project01
把project02 打包安装在本地仓库
在project03中依赖project02
然后编译项目project03
会发现project01也会在project03中
这就是传递依赖。
上面演示了传递依赖，但是如果我们只需要依赖project02 并不想依赖进来project01怎么办呢？这个时候就要是用exclusions 排除依赖列表
project03排除依赖project01pom.xml配置如下
xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"&
&zzq.mavenProject&
&project03&
&0.0.1-SNAPSHOT&
&project03&
&http://maven.apache.org&
&zzq.mavenProject&
&project02&
&0.0.1-SNAPSHOT&
&zzq.mavenProject&
&project01&
这样在project03中就不会依赖进来project01
没有更多推荐了，为什么会出现依赖冲突
首先要说明Maven的依赖管理，具体的可以参考这边
这篇文章，maven在依赖冲管理中有一下几个原则。
依赖是使用Maven坐标来定位的，而Maven坐标主要由GAV（groupId, artifactId, version）构成。如果两个相同的依赖包，如果groupId, artifactId, version不同，那么maven也认为这两个是不同的。
依赖会传递，A依赖了B，B依赖了C，那么A的依赖中就会出现B和C。
Maven对同一个groupId, artifactId的冲突仲裁，不是以version越大越保留，而是依赖路径越短越优先，然后进行保留。
依赖的scope会影响依赖的影响范围。
当出现了依赖的时候如何快速定位冲突原因
但出现了冲突的时候，比如系统出现了NoSuchMethodError， 很有可能是你系统中出现了依赖冲突。出现冲突以后，可以按以下的步骤执行
1.确定出了问题的jar包名称。通常可以在eclipse中查找冲突的类有在哪些依赖包里面出现了。并确定实际要使用的是那个包，冲突的包有哪些。
2.通过mvn dependency:tree& && tree.txt 导出全部的依赖。
3.在导出的依赖文件中，查找问题相关的jar。确定这些jar是如何被依赖进来的，是直接依赖的还是通过传递依赖引入的。
4. 找到相互冲突的并需要排除的依赖的顶级依赖,并分析冲突的原因，冲突的原因可能是以下几种：
同一个jar包但groupId, artifactId不同，这种冲突只能通过设定依赖的&exclusions& 来进行排除
需要的版本jar包依赖路径较长，这种冲突可以把想要版本的依赖直接什么在依赖中，这样路径就最短了优先级最高。
5.最后可以通过打包mvn install 来确认打出来的war包中是否有被排除的依赖。
------------------------------------------------------------------------------------------------------------------------
阅读(...) 评论()如何摆脱信息依赖？ - 知乎有问题，上知乎。知乎作为中文互联网最大的知识分享平台，以「知识连接一切」为愿景，致力于构建一个人人都可以便捷接入的知识分享网络，让人们便捷地与世界分享知识、经验和见解，发现更大的世界。353被浏览<strong class="NumberBoard-itemValue" title="1分享邀请回答10113 条评论分享收藏感谢收起8添加评论分享收藏感谢收起