QQ登录

只需一步,快速开始

 找回密码
 注册

QQ登录

只需一步,快速开始

楼主: KDE

rpm 建包原理(2010.11.22 更新)

[复制链接]
发表于 2006-9-14 08:43:25 | 显示全部楼层
…………………………
你以为 so 就象 dll 那样哪???

of course. They are the Same.
回复

使用道具 举报

发表于 2006-9-14 11:46:31 | 显示全部楼层
对dll不太了解
dll好象有很多种, 什么OLE COM COM+ 等等的能介绍一下吗
回复

使用道具 举报

发表于 2006-9-14 12:01:17 | 显示全部楼层
http://support.microsoft.com/default.aspx?scid=kb;zh-cn;815065
这里说的很详细了~~~
回复

使用道具 举报

发表于 2006-9-14 20:25:39 | 显示全部楼层

so 和 dll 不一样………………
windows 的主要 dll ,是微软随同系统一同发布,且没有源代码,不能更改的………………
回复

使用道具 举报

发表于 2006-9-15 09:11:25 | 显示全部楼层
linux的lib hell!!!!!!!!

Under Windows, you have the infamous "DLL hell", where you can have dozens
of different programs which require different versions of the same
third-party DLL with the same name.  This page --
http://www.faqs.org/docs/artu/ch03s02.html -- describes it best:

    Because Windows does not handle library versioning properly, it suffers
    from a chronic configuration problem called "DLL hell", in which
    installing new programs can randomly upgrade (or even downgrade!) the
    libraries on which existing programs depend. This applies to the
    vendor-supplied system libraries as well as to application-specific ones:
    it is not uncommon for an application to ship with specific versions of
    system libraries, and break silently when it does not have them.

Unfortunately, we've seen this under OS/2 as well, with the inability of
Mozilla-based applications to coexist without awkward workarounds.

Unix-based systems like Linux, on the other hand, avoid "DLL hell" by
linking to specific named versions of shared libraries.  Essentially, it
trades it for "lib hell" instead, where every single application can
depend on a different point version of a library, and refuse to run
until a copy of that exact version is hunted down and installed.  When you
have hundreds of programs, each of which can depend on a dozen or more
such libraries, it's enough to turn a person prematurely grey.

It's exacerbated, of course, by Linux's continued adherence to the
fundamental Unix design philosophies, notably "never implement what you
can rely on an existing program or library for".

I just finished assembling a WarpIn install package for the GIMP 2.2.8,
and the number of external libraries it depends on is insane.  (And it's
not even the worst offender by a long shot.)

At least Debian-based Linuxes have an intelligent package management
system that keeps track of all dependencies for you (and offers to
download and install them automatically if it finds them missing).
回复

使用道具 举报

发表于 2006-9-20 18:45:07 | 显示全部楼层
autopackag刚刚用了一下,感觉和rpm类似,只是图形化而已,缺少的包还是要自己去下载。
装giam运行结果:
[code:1]
Checking for required C library versions ...  OK
Checking for GTK+ user interface toolkit ...  OK
Checking for Audio File Library ...  OK
Checking for libao cross platform audio library ...  OK
Checking for GtkSpell Spell Checking Library ...  failed

Error: Could not find 'GtkSpell Spell Checking Library'. Try using the native package manager for Mandriva Linux (urpmi) to install a package with similar name to 'gtkspell'.

Error: Unable to prepare package Gaim Internet Messenger.
[/code:1]
等会试试klik
回复

使用道具 举报

发表于 2006-9-20 19:27:14 | 显示全部楼层
klik比autopackage聪明多了,就像apt比rpm聪明一样,它会下载所需的deb包装上,自己解决依赖关系,可以试试。 总之一句话,只要上网,依赖关系就可以解决!

关于前几天讨论的自带库的rpm问题,现在我有了新的想法。跨发行版安装基本不行,(有些极端的手段也许可以,但是问题很多)。二进制层兼容性很差。不像windows只有一家在发行系统二进制库,linux的发行版太多了(据说有386个。。),编译环境,库的版本(linux lib hell)都不一样,这里运行好好的程序拿到另一个系统就有问题。

linux什么时候才能统一呢?如果只有一个linux发行版,一种桌面环境,就不用考虑跨发行版带来的种种问题,那样的话安装一个新软件会容易的多。。 :neutral:
回复

使用道具 举报

 楼主| 发表于 2006-9-20 20:44:53 | 显示全部楼层
[quote:68b74396c7="linuxpgy"]klik比autopackage聪明多了,就像apt比rpm聪明一样,它会下载所需的deb包装上,自己解决依赖关系,可以试试。 总之一句话,只要上网,依赖关系就可以解决!

关于前几天讨论的自带库的rpm问题,现在我有了新的想法。跨发行版安装基本不行,(有些极端的手段也许可以,但是问题很多)。二进制层兼容性很差。不像windows只有一家在发行系统二进制库,linux的发行版太多了(据说有386个。。),编译环境,库的版本(linux lib hell)都不一样,这里运行好好的程序拿到另一个系统就有问题。

linux什么时候才能统一呢?如果只有一个linux发行版,一种桌面环境,就不用考虑跨发行版带来的种种问题,那样的话安装一个新软件会容易的多。。 :neutral:[/quote]
绕了一圈,你终于明白了,可喜可贺。
回复

使用道具 举报

发表于 2006-9-20 20:52:20 | 显示全部楼层
解决的最好办法就是提供从源代码编译!
回复

使用道具 举报

发表于 2006-9-21 08:53:22 | 显示全部楼层
原代码编译?
首先,并不是每个人都装了gcc,及所有编译所需的sdk,其次,不是每个人都是编程狂人,能应对编译错误,再次,不是每个人都能忍受漫长的编译时间……所以这种方法不适合普通用户。

既然magic也是基于rpm管理的,rpm不能跨平台,所以为这个平台打包的软件必须丰富起来,不然要装anjuta之类的还需要其他发行版的包。有个非官方的软件包,做的很不错,如果有更多适合magic的rpm就好了。   所以我觉得magic应该在做rpm上加大力度,系统的升级可以慢一点,平时补丁打打就好了,这样我相信magic会成为中国唯一的linux的。

magic也有apt源,不知道里面有什么软件,里面很多吗?
回复

使用道具 举报

发表于 2006-9-21 20:10:48 | 显示全部楼层
开发人员数量决定软件包的数量…………
回复

使用道具 举报

发表于 2006-9-28 17:33:58 | 显示全部楼层
我有个问题  急盼回复   这是我的SPEC

ummaryhotoDVD is a very sample application which enables you to create and burn photos slideshow to DVD.

Name: PhotoDVD

Version: 1.0

Release: 1mgc

Copyright: Commercial

Group: Graphics

Source0:%{name}-%{version}.tar.gz

%description
PhotoDVD helps you use DVD or CD burner to create photo album on DVD disc playable on TV with background music, a lot of pictures, transition effects.
%prep
#tar xzvf $RPM_SOURCE_DIR/%{name}-%{version}.tar.gz -C $RPM_BUILD_DIR/

%setup -n %{name}-%{version}
%build

%install
mkdir  /Colorlife
mkdir -p /EB_Workshop/EB_Dependence

cd $RPM_BUILD_DIR/%{name}-%{version}

cp -R Lib /EB_Workshop/EB_Dependence
cp -R MainconCeptLib/*  /usr/lib
cp -R sharedlib/* /usr/lib
cp -R PhotoDVD /Colorlife

%clean
rm -rf $RPM_BUILD_DIR/PhotoDVD

%files
%defattr(-,root,root)
/Colorlife/PhotoDVD/
/usr/lib/libipp*.so
/usr/lib/libmcmpgvout.001
/usr/lib/libmcmpgvout.002

%changelog


然后我 rpmbuild -ba PhotoDVD-1.0-1.spec

生成的PhotoDVD-1.0-1mgc.i386.rpm  
两个问题
我在干净的环境中第一次运行 程序总是报错 启动不了.
2.我在另一台机器下安装,根本就没有CP
回复

使用道具 举报

发表于 2006-9-28 19:16:30 | 显示全部楼层
错误信息是什么?详细一点
回复

使用道具 举报

 楼主| 发表于 2006-10-2 01:15:58 | 显示全部楼层
to: ququ01
1、你根本就没有仔细阅读 rpm 建包原理,严重违反了一些基本建包原则。
2、你在 %files 丢了东西,难道你在执行 rpmbuild -ba PhotoDVD-1.0-1.spec 就不看看错误输出么?
3、我们不会对不开源的商业软件提供任何额外的无偿 rpm 建包技术支持。现有文献就是你最好的学习资料。
回复

使用道具 举报

发表于 2006-10-8 10:04:00 | 显示全部楼层
KDE
请你帮帮我  我知道%file下缺的一些东西
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

GMT+8, 2024-4-18 13:24 , Processed in 0.170415 second(s), 12 queries .

© 2021 Powered by Discuz! X3.5.

快速回复 返回顶部 返回列表