怎么在 spec 文件里依赖其他软件源（非主源）里的包
按照我的粗浅理解，spec 文件里写的依赖，只是写依赖某个软件。rpmbuild 编译的时候并不在意这个软件是来自哪个源，只要在你的编译环境里能找到这个软件。
比如你完全可以在 spec 里写依赖 ABC 软件，这个软件可以不是主源里，只要你的机器上安装了 ABC 软件，编译就可以通过。
我想你的问题是给 OBS 编译环境添加不在主源里的软件。因为 OBS 里默认的环境只是安装了主源里的软件。这个不是在 spec 里改的，而是在 OBS 里设置。
这个可以去 OBS 的网站设置，也可以改本地的 OBS 配置文件。我记得以前我有写过… … 具体看图。
就在那个 Add additional path to this repository，你可以其他仓库添加到这个做为依赖。
不过我记得女王大人在哪里说过最好的方法是直接把你依赖的那个仓库克隆一份，在那个仓库里打你的包… 我也好久没有打过包了… 有点遗忘…
我是 branch 过来的仓库，找不到那个 “Add additional path to this repository”
在这里：-）
这就不是 spefile 应该干的事啊…
在 OBS 上编译软件，依赖包的查找路径是这样的：
- 那个包所在的源里有依赖，用源里的。
- 软件源的 meta 里面有 path，可以用其它软件源的。
- oss 源里有，用 oss 的。
所以你就有两种办法：
- 通过派生（branch）或链入（aggregate）到源的方式。
派生上面 PaleFire 已经说了。什么，网页界面找不到？osc linkpac 或者 osc copypac 能适用所有情况，其中 linkpac 就是别的源有变化，你这里也跟着变，而 copypac 就是复制了一个别的源里的包工程。另外说下链入，链入（aggregate），也叫聚合，意思就是直接从别的源拷贝编译好的 RPM 来用，毕竟不管你是在你的源里编了，还是拿别的源编好的 RPM 直接用，最终提供依赖关系的还是 RPM。链入的好处就是快速和相对静态，快速好理解，省去了编译的时间，相对静态就是编译过程实际上并不发生在你的源里，而 linkpac 也好，copypac 也好，最终还是要在你的源里跑一遍编译才有 RPM 生成 ; 而链入的坏处也很明显，就是它的目标（target）不好确定，比如原始源只针对了 13.2 编译，而你的源里有 13.1，那 13.1 部分的依赖就解决不了，因为原始源里就没有 13.1 对应的 RPM。
- 通过编辑软件源的 meta 加 path 的方式
实际上你去 branch 一个别的源里的软件包，加工，再提交回去，这个过程你的 home:torbai:branches:xxx 源的 meta 里就不只有 oss 源的 path，还有你 branch 的源 xxx 对应的 path。好理解吧，万一你 branch 的那个软件包用到了原来源里的其它包做依赖呢？如果没有原来的源的 path，你的编译不就缺少依赖了？所以理解了这个原理，你也可以通过 osc meta prj -e home:torbai:xxx 来给你的源加 path 来实现直接使用其它软件源做依赖的目的。但是它的对象是一整个源，比如它的源里有比较新的 glibc，那么你的软件包实际上最终编译时使用的是这个比较新的 glibc 而不是 oss 源里的。
总之都有好处也都有缺点，看情况自己选择吧。