Linux开发人员为什么不能创建通用打包格式?


14

供应商二进制软件包格式的选择似乎由某种形式的墨菲定律决定:您使用的所有发行版都具有软件包。(Corralary:不存在满足您软件堆栈的分发依赖关系的分发)。

这是政治问题还是更深层次的问题,而我们还没有看到“一次构建,可以在任何地方运行”软件包格式的出现?


3
您似乎对不同的分布之间只有肤浅的了解。统一软件包系统仍不意味着软件包在发行版之间是可互换的。因此,您的问题毫无意义。

3
啤酒花,为什么不写一个答案,对分布之间的差异进行较简单的描述呢?这个问题很幼稚,但是还有很深的技术答案需要等待。
jldugger

您真的在寻找“ Linux标准库”
Bill Weiss,

Windows开发人员为什么也不能创建通用打包格式?这里不给Windows套袋,但是它们有许多种安装软件的方法,并且没有像Linux这样的单一存储库……(这是一个反问的问题,顺便说一句)
Mark Henderson

Answers:


24

在这一点上引用Joel Spolsky似乎是适当的:

(顺便说一下,对于那些遵循神秘但带有政治色彩的博客联合供稿格式的人来说,您会发现那里发生了同样的事情。RSS变得支离破碎,有几种不同的版本,不正确的规范和许多政治斗争,尝试通过创建另一种称为Atom的格式来清理所有内容的结果导致出现了几种不同版本的RSS和一种版本的Atom,不准确的规范以及许多政治斗争。当您尝试通过创建第三种替代方案来统一两个对立的力量时,最终会受到三种相反的力量的影响。您还没有统一任何东西,也没有真正固定任何东西。)

(添加了重点)

您拥有(至少)两个用于Linux的打包系统。这实际上是一件好事。单个系统将简单地创建第三个系统。


回复:当您尝试通过创建第三个备选方案来统一两个对立的力量时,最终只会遇到三个对立的力量。 另请参阅xkcd.com/927
JamesBarnett

20

造成这种情况的原因有很多,为了使事情更加清晰,需要一些历史。

请记住,当我们谈论“ Linux”时,我们通常指的是许多不同的Linux发行版之一。“ Linux”实际上只是一个操作系统内核。

Linux的最初目标是创建一个可在PC(最初为386)上运行的基于Unix的系统。第一步是创建内核本身。当Linus Torvalds在内核上工作时,Richard StallmanGNU(GNU的非Unix)项目下开发自己的Free Unix系统。简而言之,这两者在某种程度上融合在一起,因为GNU具有相关的实用程序(C编译器/库/构建工具,shell,文本编辑器等),但是没有运行该程序的核心,而Linux具有该程序的核心但没有实用程序在它上面运行以使其对大众有用。

这种融合在某种程度上被正式称为GNU / Linux。您将看到,许多发行版仍将自己称为GNU / Linux发行版。

由于GNU / Linux的自由和开放性,因此任何人都可以选择它并创建符合他们特定口味的捆绑系统。结果是,使用了许多不同的,采用不同配置方法的流来创建这些系统,这具有创建几乎相同数量的不同软件包管理系统以适合每个系统的副作用。

多年来,每个不同的完整系统都有其自己的强大追随者,他们始终坚持不懈,形成了今天的今天:少数广泛使用,根深蒂固且稳定的软件包管理系统,例如RPMAPT / dpkg和Gentoo的Portage

有一些项目,例如Autopackage,正在尝试解决该问题,但是各种受支持的软件包管理系统的不断发展意味着有许多需要遵循的目标。

一些软件供应商最终要做的是将他们所需的特定二进制文件和依赖项副本捆绑到一个可以在特定系统上工作的大型软件包中。


8
不仅如此。即使整个世界都统一说rpm,您仍然不会拥有该软件包,而是可以在OP设想的任何地方运行。程序包大部分是特定于其发行版的,因为它们依赖于所有其他程序包。拥有“一次打包,随处运行”世界的唯一方法是不仅拥有单个打包系统,而且只有一个发行版。
Cian

9

无论如何,使用相同的软件包格式将无济于事。您只是不能在其他发行版中使用相同的软件包。您甚至不能经常在同一发行版的不同版本中使用它。甚至构建软件包也可能遇到相同的问题。

要安装软件包,您需要满足在构建软件包期间形成的依赖关系。要构建软件包,您需要满足构建依赖性。这些事情发生了变化。为了能够实施更改,仅支持您可以修改以在更改后工作的程序包更容易。

如果所有依赖项都相同,则不会是不同的发行版或同一发行版的不同版本。


4
版本库和使用版本依赖性解决您提到的问题是否可行?
jldugger

您提到您不能在一个版本的另一个版本上使用deb。这并非完全正确,该规则也有例外。如果软件包主要是python,或者所有位都是静态编译的,则可以。甚至有几家供应商只是将所有依赖项作为软件包的一部分包含在内,这浪费了磁盘空间,但却制作了跨平台的软件包。
Zoredache

即使软件包是arch:all或脚本语言,python2.4和python2.6之间也存在显着差异,这将导致软件包在为其构建的平台上工作,而在其他平台上失败。
jldugger

是的,这不仅与库依赖关系有关。
2009年

一些debian更新已经更改了应该放置文件的位置,或者提供了用于更新配置文件的标准化系统,这些配置文件以前是手动管理的..这种事情是非常特定于版本/发行版的。
pjc50

7

我认为有些“这里没有发明综合症”。Debian的打包系统早于RedHat,但是它在许多方面都比较出色,但是您永远不会看到RedHat切换。取而代之的是,您看到许多人在使用“ apt-rpm”,试图为您提供apt和rpm文件的一些优点。


4
apt-rpm已经死了好一阵子了(最近的发布时间是1.5年前),大多数人已经开始使用yum。百胜餐饮本身提供了许多不错的功能,
胜过

1
我不相信Debian的包装会比今天的Redhat更好。曾经是Debian有一个更好的更新系统,但是到目前为止,这似乎不再是真的。百胜变得非常好。与Smart相比,它仍然很慢,但是非常易于管理。
niXar,2009年

1
我所知道的是,上一次我在CentOS上工作时,我们更有可能陷入依赖地狱,而切换到apt-rpm可以解决大多数这些问题。
Paul Tomblin,2009年

1
Redhat的RPM包装患有EDS(极端依赖综合症)。这不是对RPM的评论,而是Redhat。Yum是apt-get和apt-search的很好的副本,它为以前不可思议的RPM命令行调用世界带来了可用性。
kmarsh

3
实际上,.deb和.rpm软件包格式在技术上甚至差不多(但是,IMO .deb具有更好的依赖性处理,尤其是版本依赖性,提供,冲突和虚拟软件包)。apt-get是在技术层面上崭露头角的东西,但真正使debian的软件包脱颖而出的是一组定义明确的开发人员策略,这些策略设置了软件包必须遵守的标准。ubuntu包在很大程度上继承了它,并且ubuntu也继承了它所伴随的开发人员文化。
cas



2

我认为克莱特斯,韦恩和伊尼对此回答很好。我真的想补充一下,这没什么大不了的。我在混合环境中工作,其中有Gentoo(端口),SUSE(rpm / zypper)和OpenBSD(程序包和端口)。在其中任何一个上安装软件包并不困难,我也不在乎它们使用什么格式。

从打包软件的角度来看,这也不是很难。无论是Gentoo,基于RPM的发行版还是基于deb的发行版,它实际上都归结为用于构建软件和添加一些元数据的配方。如果您要打包的构建系统不是完全疯狂,通常只需要编写一个美化的shell脚本即可创建一个包。



1

对于“ Linux”,没有标准二进制接口的定义,因为它只是一个内核。奇怪的是,您的软件堆栈不仅需要与内核交互,还面临维护数百个不同源代码树之间的标准ABI的特殊挑战。

关于好的打包工具,我更喜欢Debian GNU / Linux,因为它具有出色的二进制打包格式。它满足了我对标准工具和应用程序90%的需求。剩余的10%由于包含非自由组件或共享库有故障,因此是从源代码构建的。当需要部署这些应用程序时,我将为生产集群构建自定义二进制文件。


1

要一次构建,可以在任何地方运行包格式,而不必强迫每个人使用相同的发行版,您需要几个重要的功能:

  • 全局唯一的软件包命名,这样两个人/发行人就不能独立地创建具有相同名称的不同软件包。

  • 当软件包有冲突的要求时,可以并行安装不同版本的库。发行版可以决定要使用每个库的版本,并强制所有软件包使用该版本。跨发行版运行的系统必须更加灵活。

零安装提供这两个功能:

  • 名称是URI(例如http://rox.sourceforge.net/2005/interfaces/ROX-Filer)。默认情况下,只有域的所有者才能在该命名空间内创建包。

  • 每个软件包的每个版本都位于其自己的目录中。每个应用程序仅能看到所需的库以及兼容的版本。

例如,Edit应用程序依赖于Python <3,如下所示:

<command name="run" path="Edit/AppRun">
  <runner interface="http://repo.roscidus.com/python/python">
    <version before="3"/>
  </runner>
</command>

另请参阅:http : //www.osnews.com/story/16956/Decentralized-Installation-Systems

[注意:我是0install开发人员]

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.