[轉貼] Ubuntu 是否會變成 Debian 相容性的夢魘?

[訪客]

如果 ubuntu 提供的東西, 是多數的人所需要的, 自然會吸引多數的人去使用它. 這是 ubuntu 的錯嗎? 還是 debian 的錯呢?

按照這個邏輯，如果過幾天 Debian 團隊卯起來幹活，半年之內完成好幾個版本，多增加許多大家喜愛的套件，那不是要換 ubnutu 的 user 叫了嗎？

我覺得有一個標準存在，就應該跟隨標準，除非真的有更好的方法，
不然就有點浪費了大團體資源，重複的在做相同的工作，實在不是一件好事。

陰謀一點說，微軟說不定正在拍手叫好呢

其實如果按照這個邏輯，更可能的促進模式應該是我們所有linuxer
通通轉到最普及的windows下，去開發，去使用，
共同改善windows，而不是在這裡爭論哪個linux套件疏離
了「標準」

[caosheng]

上面一直說標準標準的，究竟標準是什麼？

上面提到的 glibc不知道是不是假設，我剛剛抓 ubuntu hoary 和 debian sid 的 glibc source 下來，分割完全沒有差異。diff 的結果只看到 ubuntu 增加了install-language-locales, remove-language-locales 兩隻程式，所以會多安裝這兩個。

我是意外在ubuntu升級了debian的libc6
結果就造成ubuntu的語系介面變成英文

我覺得ubuntu 要重新包裝任何 DEBs 的話，應該考慮相後相容的問題
如果需要patch 儘量在不影響原deb內容狀況來補充功能
最好是多一個xxx-ubuntu-support 之類明瞭的套件，而儘量不要在原碼patch
等於說debian使用者 如果想要使用某些ubuntu加強的功能直接套上這些support就可以享受某些功能

又譬如我提到的firefox 的問題，為了速度效能換了自己重編的firefox (debian 的源碼為底，編譯時間太久了懶的recompile)
結果所有的gnome說明文件瀏覽器、about之類的通通無法喚起了

[BBNS]

yes, that's exactly what I mean.
That's the 'standard'.

[BBNS]

其實如果按照這個邏輯，更可能的促進模式應該是我們所有linuxer
通通轉到最普及的windows下，去開發，去使用，
共同改善windows，而不是在這裡爭論哪個linux套件疏離
了「標準」

如果對標準真的只是"微軟"的定義，那麼真的就是這樣。
自由社群有自己的方法，標準不代表統一，只是一種讓人方便交流溝通的方法。

很含糊吧?
要我短時間內提出明確"標準"的定義是沒辦法的，現在也只能明白攤手說自己做不到。Debian的制度花了多少時間，有多少人在構思，我的涉世不深，研究的領域也只有一小塊而已，對於像我這種門外漢而言只是以管窺天。

但是開放系統沒有所謂的標準麼?
這麼多年來只是看到一再重複的造輪子而已，這些新推出的套件們有什麼革命性的改革麼?

真正有幫助的，不是這些"套件"，而是那些"軟體"。
Xorg或是KDE的開發人員並不會去區分誰用了什麼套件，但是mailing-list上，因為套件彼此間的標準不同，而引起的問題的確花了不少開發人員的時間。

若是沒有這些隔閡呢?
到底有沒有可能做到不是我有資格下評論的，但是若是沒有這些隔閡的確可以省下很多力氣在處理套件的問題上，然後更專注於新軟體的開發。Linux的確提供很多的自由，但是現在的確是該思考該不該賦予一些限制的時候了。

[granziliao]

我只想說，現在是車同軌，人同文的時代。
這樣無異是在開倒車。

恕我直言，如你所言，則那些口吐母語，使用英制的也是該進墳墓，被時代淘汰的一群了，可是沒有，現在世上最大尾的國家使用英制，我國學校裡教授母語，實際而言，sourceforge上的專案大部份都是以source code tar package發行的、如果你堅持標準、那每次更新／安裝軟體時 configure、make、make install的三部曲都要再唱一次、難道不嫌麻煩嗎?
照您的邏輯，恐怕這些cutting edge programmer也是麻煩制造者了，就binary package而言，我們何不從rpm的使用者的立場來看deb呢？
道不同不相為謀，強要送作堆實在不那麼健康
就像scim的蘇先生抱怨gcin錯置了一些人力資源，那何不想想因為scim不能滿足他們的需求，只好另起爐灶？
linux己有LSB等標準，或許還不夠仔細，好避免相容性問題；咸信未來會有更好的解決方案（很不幸的，如果是多數決，又只容許單一套件管理系統（我指的是“低階的dpkg , rpm不是高階的apt),dpkg很可能就出局了） 但是，只要這個世界有不止一個人，相容性問題就會永遠存在，在我們統治世界前，先看看別人在想什麼吧

[caosheng]

我覺得關鍵是所有軟體能否在同一個平台環境上做開發
windows NT 平台上的所有軟體不也都能在95 98 me / NT 2000 XP上運行？
java 軟體不也都能在1.4 / 1.5 的標準上運行？
python 不也都能相容於2.3 / 2.4版本，perl php 等類同

既然ubuntu 脫胎於debian 也應該能在debian 相容的libc6 x-window gtk qt 等，這些lib環境上跑軟體

說真的如果ubuntu 相容性差太多的話
我肯定會選擇套件最多的、社群支援最力的那一套來使用
現在ubuntu 只是發現些小問題，對比起來優勢相當明顯
大部份debian 上的安裝操作習慣，都可以在ubuntu上實現
一切都要看使用者自行選擇的結果
先有人使用才會有人改進，不然就慢慢沒落或者侷限一小圈子

[BBNS]

恕我直言，如你所言，則那些口吐母語，使用英制的也是該進墳墓，被時代淘汰的一群了，可是沒有，現在世上最大尾的國家使用英制，我國學校裡教授母語，實際而言，sourceforge上的專案大部份都是以source code tar package發行的、如果你堅持標準、那每次更新／安裝軟體時 configure、make、make install的三部曲都要再唱一次、難道不嫌麻煩嗎?
照您的邏輯，恐怕這些cutting edge programmer也是麻煩制造者了，就binary package而言，我們何不從rpm的使用者的立場來看deb呢？
道不同不相為謀，強要送作堆實在不那麼健康
就像scim的蘇先生抱怨gcin錯置了一些人力資源，那何不想想因為scim不能滿足他們的需求，只好另起爐灶？
linux己有LSB等標準，或許還不夠仔細，好避免相容性問題；咸信未來會有更好的解決方案（很不幸的，如果是多數決，又只容許單一套件管理系統（我指的是“低階的dpkg , rpm不是高階的apt),dpkg很可能就出局了） 但是，只要這個世界有不止一個人，相容性問題就會永遠存在，在我們統治世界前，先看看別人在想什麼吧

您說的理由是"現實"，但是不代表合理。
有很多"現實"是不合理的，我相信現實生活中很多例子，不必一一說明，如果按照您的邏輯，那麼人類就繼續維持這個現狀活下去就好了。有很多現有的方法和制度是礙於現實，但是不表示未來也就是如此。

您不必接受我的想法，但是我的想法您仔細想過了麼?
套一句您說的話：在我們統治世界前，先看看別人在想什麼吧。

[granziliao]

恕我直言，如你所言，則那些口吐母語，使用英制的也是該進墳墓，被時代淘汰的一群了，可是沒有，現在世上最大尾的國家使用英制，我國學校裡教授母語，實際而言，sourceforge上的專案大部份都是以source code tar package發行的、如果你堅持標準、那每次更新／安裝軟體時 configure、make、make install的三部曲都要再唱一次、難道不嫌麻煩嗎?
照您的邏輯，恐怕這些cutting edge programmer也是麻煩制造者了，就binary package而言，我們何不從rpm的使用者的立場來看deb呢？
道不同不相為謀，強要送作堆實在不那麼健康
就像scim的蘇先生抱怨gcin錯置了一些人力資源，那何不想想因為scim不能滿足他們的需求，只好另起爐灶？
linux己有LSB等標準，或許還不夠仔細，好避免相容性問題；咸信未來會有更好的解決方案（很不幸的，如果是多數決，又只容許單一套件管理系統（我指的是“低階的dpkg , rpm不是高階的apt),dpkg很可能就出局了） 但是，只要這個世界有不止一個人，相容性問題就會永遠存在，在我們統治世界前，先看看別人在想什麼吧

您說的理由是"現實"，但是不代表合理。
有很多"現實"是不合理的，我相信現實生活中很多例子，不必一一說明，如果按照您的邏輯，那麼人類就繼續維持這個現狀活下去就好了。有很多現有的方法和制度是礙於現實，但是不表示未來也就是如此。

您不必接受我的想法，但是我的想法您仔細想過了麼?
套一句您說的話：在我們統治世界前，先看看別人在想什麼吧。

在下的意思並非把現實狀況繼續放給它爛，而是說在希望一些事情照著我們的願望發展時，先去理解一下是什麼因素造成我們現在所遇到的現況和問題，ubuntu和debian的相容性問題並不是像Redhat和Suse那樣，連檔案目錄，設定檔的安排的方式都大大不同，只是在gnome的軟體部份有大一些的差異，這些差異便是ubnutu存在的理由的一部份。相信各位都願意看到linux能更普及，也希望linux使用起來能更方便，不需去處理太多的相依性（apt己經作得不錯了），相容性（這就是一個大問題了，牽涉到應用軟體的收錄與更新)問題，但是這些是工具，它們會長成有需求的人所希望它們長的樣子，如果你嫌醜嫌跛，何苦去用呢？
像ubuntu這樣打算和debian一樣作到包山包海的distribution一定會遇到這些問題的
ubuntu不是它所有的更改都是合理的，你如果用hoary裡的firefox去看mathml就知道有些部份確是削足適履（強要用firefox作epiphany的backend)

[redjoe]

問題出在相容性上,

debian是以穩健著稱,且具彈性,

ubuntu給人的印象是相容於debian,
但事實上是ubuntu開發及更新速度快於debian,那就不是相容了,
在source是open的情況下,說更新速度快的ubuntu相容於debian,是不合理的,

用了兩個多月的ubuntu,每天更新都有一堆東西,這些更新當然是好事,
只是覺得之前的設計or處理並不夠嚴謹..

目前看來,要把ubuntu視為另一套不相容的distribution來看待..

那篇文章就是把ubuntu當成另外之distribution的意思..

[BBNS]

抱歉 我Debian已經用了六年，一年365天24小時開機，除了當機以外沒有中斷過，也沒有中途換過其他的套件，幾乎所有日常生活的瑣事都在Debian上解決。在使用Debian前用過slackware、RedHat和Mandrake，林林總總用了一年。如果真的嫌它爛，那麼我就不會一口氣用了這麼久。

老實說，有很多問題要真的用很"久"才會碰到。
一年365天24小時開機，六年之間不曉得Debian已經換過幾個世代了，資料的維護和系統升級的work是難以想像的。光是處理一些諸如KDE 2.2升級到KDE 3.0之間設定檔的問題就非常的麻煩，更別提幾年前glibc全部換成3.0的惡夢。還有中文環境，幾年前還是非常破爛不堪，Qt上的bug導致中文漏字和輸入法無法正常運作，不曉得花了多少時間寫patch，以及和DD們交涉才終於修成現在這個樣子。

如果只是嚐嚐鮮，抱歉我不是。
您可以反駁我，但是請別用現在已知的問題，這種文章太容易了，能舉的例子太多但是也沒建設性。Mandrake當初的情形就如同現在的Debian和Ubuntu，號稱和RedHat相容，我用的結果發現是個狗屁。現在Mandrake茍延殘喘，很難想像以前它是多麼的風光，光鮮的安裝介面，改善一些RedHat上的毛病，雜誌上寫的好處多到說不完。

我不清楚Ubuntu的那些高層打算如何做，但是我只能誠摯的希望那些拿Debian基礎發展的人，能夠做一點回饋給Debian社群，而不是造成Debian社群的分裂。Ian的想法就是希望所有Debian-Based的系統都是大家庭，沒有隔閡而且能夠互相交流。Ubuntu的員工有錢可拿，Debian的DD可沒有，但是Debian的DD要做的事情可不比Ubuntu的少。在您享受Debian的恩惠之前，請您想想這個系統花了多少人完全義務的幫忙。Ian創造了Debian，卻沒有多少人記得他帶來的貢獻。他開的公司經營不善以後，不是將成果出售，而是全部奉獻給Debian。這種人不可敬麼? 努力幫他達成夢想是這麼的困難麼? 是種罪過麼? 您知道Debian互助和包容的精神麼? 您對Debian花了多少心思貢獻多少心力呢? 它不只是工具，它是一個生命共同體，所有的人各取所需也貢獻所長，然後逐漸成長。我在上面耗費了泰半的光陰和心血，所以不願見它凋零。

很可惜，一些人的意見讓我感到嘆息。反駁或是放著任憑它們分裂，而不是合作，這就是所謂的Human being精神? 個人發表的文章無異是希望凝聚一些看不見的力量，讓Ubuntu和Debian都能有所改變，而且是往好的方向。

現在我的時間不多，這是少數能提供貢獻的地方，現在需要大家的力量去影響Ubuntu和Debian的發展。很久很久以前，在摩扥學園還沒建立的時候，Debian很難照顧到中文的使用者。現在摩托學園的確有它深遠的影響力，其中令我受惠最深的就是中文輸入法的改進，進展速度之快是以前無法想像。

不要忽視自己的力量，您的一言一行對於整個社群都有深遠的影響，影響日後Ubuntu和Debian的發展。既然現在已經有前車之鑑，就應該要避免或是減少到傷害性最小，而不是說不可能或是不可行。沒有什麼做不到的，只要使用者想這麼做，開發人員就會想辦法。從前的KDE簡直是爛到一種境界，又肥又大，三不五時還會有中文問題和Segmentation Fault。從KDE 3.0開始，一碰到問題我就開始寄信，不厭其煩的將碰到的bug或改好的patch回報給KDE的Bug Track，現在問題通通不見了，KOffice上也不再有中文亂碼的顧慮。個人的力量還是佔有一席之地的，即使不是開發人員，能夠改變的事情也是很多很多。

[訪客]

是不是有哪位先進可以說明一下 Ubuntu 跟 Debian 兩邊在包 deb 的不同點

[BBNS]

剛剛去看了一下Ian Murdock的原始文章，一位仁兄個人覺得寫的不錯:
http://ianmurdock.com/archives/000244.html

As I see it Ubuntu's relationship with Debian is it's biggest strength.

I don't know were all this debian-hate is coming from, but it's realy pathetic.

What Ubuntu does is take the top-notch work that Debian developers have done and built a polished default desktop configuration on it.

If Ubuntu drifts to far away from Debian then they will loose this benifit and will be forced to do all the developement on the OS themselves and not be able to create such a polished default install.

What it needs is Debian working on the OS itself and Ubuntu taking that base and configuring and updating select packages for end users that don't have the time, desire, or the skills to do it themselves into a proper desktop.

As far as Debian being out of date. Just use Sid or Sarge.

You know that Sid ships with 2.6.11 kernels right? How out of date is that? Installing Java and Flash is the exact same in Debian as it is in Ubuntu...

How can Debian be so far out of date, but Ubuntu not, when Ubuntu uses 90+% packages from Debian?

Ubuntu needs Debian to do the grunt work, while Debian needs Ubuntu to create a polished default install for a Desktop.

All this Debian vs Ubuntu crap is in your guy's heads. It never was a conflict, there is no contest or Debian developers being pissed off, or any hatred or rivalry.

This is not a fork, this is not a them vs us, or a XFree vs X.org. It's not like this.

Debian was specificly created to be a universal, generic operating system. It's maintains a high degree of division between Free and non-Free specificly so that people like Ubuntu can use it without having to f*k around with licenses or weed out illegal or otherwise restricted software.

It's like arguing Pontiac vs Chevy cars, when they are both owned by GM and both sell the same cars with different configurations and body panels.

What this guy is saying is that Debian and Ubuntu need to keep a high amount of compatability so that YOU AS A END USER can have the benifits of having software that works across the board.

There is no point in diverging to far because you would end up with each other needlessly duplicating the same work and wasting resources that can otherwise be used to stabilise and improve the operating systems.

Posted by: Drag at April 11, 2005 11:35 PM

[huangjiahua]

我发现 deb 包不相容的情况很多时候都是因为 版本号

Ubuntu 的很多包版本好都有 ubuntu 后缀 ， 而 dpkg 似乎处理这种有后缀的版本号有些问题

像这个同样的 eva （ KDE 上一个 IM 软体 ）的 deb 包， ，用 dh-make 生成的框架
debian/control 里面都是
Depends: ${shlibs:Depends}, ${misc:Depends}



但是 ， 在 Ubuntu 下编译，是
Depends: kdelibs4 (>= 4:3.4.0), libart-2.0-2 (>= 2.3.16), libaudio2, libc6 (>= 2.3.2.ds1-4), libfontconfig1 (>= 2.2.1), libfreetype6 (>= 2.1.5-1), libgamin0, libgcc1 (>= 1:4.0-0pre6ubuntu4), libice6 | xlibs (>> 4.1.0), libidn11 (>= 0.5.2), libjpeg62, libpcre3 (>= 4.5), libpng12-0 (>= 1.2.8rel), libqt3c102-mt (>= 3:3.3.3), libsm6 | xlibs (>> 4.1.0), libstdc++5 (>= 1:3.3.4-1), libx11-6 | xlibs (>> 4.1.0), libxcursor1 (>> 1.1.2), libxext6 | xlibs (>> 4.1.0), libxft2 (>> 2.1.1), libxinerama1, libxrandr2 | xlibs (>> 4.3.0), libxrender1, libxt6 | xlibs (>> 4.1.0), zlib1g (>= 1:1.2.1)




在 Sid 下编译， 是
Depends: kdelibs4 (>= 4:3.3.2-4.0.2), libart-2.0-2 (>= 2.3.16), libc6 (>= 2.3.2.ds1-4), libfam0c102, libgcc1 (>= 1:3.4.1-3), libice6 | xlibs (>> 4.1.0), libidn11 (>= 0.5.13), libjpeg62, libpcre3 (>= 4.5), libpng12-0 (>= 1.2.8rel), libqt3c102-mt (>= 3:3.3.4), libsm6 | xlibs (>> 4.1.0), libstdc++5 (>= 1:3.3.4-1), libx11-6 | xlibs (>> 4.1.0), libxext6 | xlibs (>> 4.1.0), libxrender1, zlib1g (>= 1:1.2.1)



结果 Ubuntu 下做的包拿到 Sid 下安装就报依赖不能满足 ， 反之依然
而实际上都是可以正常执行的

[訪客]

其實debian的套件的機制，
也沒好到哪裏去，與其擔心
未來的相容性的問題，不如
先把底層他原本的相容性的
問題先解決吧，作事首重治
，真搞不懂一堆人研發的套
件機制，充其量只能發揮到
debian這樣而已，說實在的
，debian只是把rpm的流程
當中，需要手動的部分，加
以便利性罷了，但根本上的
套件的相依性的問題還是沒
有解決，吾人只是想下載一個
古老的debian，安裝並用簡單
的指令，就可完全無錯誤的升
級至最新版本，不要管什麼
dist-upgrade or 單純的upgrade，
吾人只想用upgrade 不是嗎?
相依性的問題，我管你那麼多?
不然debian弄一個套件管理的機
制要幹嘛? 豈不是毫無用武之地?

一個觀念，觀念要正確，然後再來
作事情，作套件的機制的目的是要達
到什麼? 沒有達到，你release出來幹
嘛?

[Tetralet]

個人並不是很清楚像是 RedHat 的 rpm 機制已方便到什麼程度，
畢竟太久沒碰了；
也不清楚 Debian 的套件的機制有什麼不方便的地方，
（也許 Debian 個人玩得太少了）
不過...

其實debian的套件的機制，也沒好到哪裏去

我的系統基本上是 Sarge，
但實際上是 testing + unstable + experimental，
亂得不像話。

以 XFree86 為例，
在我的系統上的版本就有：

代碼: 選擇全部

ii  xserver-xfree86               4.2.1-15
ii  xfree86-common                4.3.0.dfsg.1-8
ii  xlibmesa-gl                   4.3.0.dfsg.1-10
ii  xlibmesa-glu                  4.3.0.dfsg.1-10
ii  xlibs                         4.3.0.dfsg.1-12             
ii  xlibs-data                    4.3.0.dfsg.1-12


從 4.2.1-15 到 4.3.0.dfsg.1-12 都有，
但我的系統在使用上幾乎沒有遇到什麼問題。

前幾天把 GIMP 從 Sid 的 2.2 版硬是降到 Woody 的 1.2 版，
把 KDE 的一些核心程式 kdelibs-bin kdelibs4 昇級至 3.40，
但我的系統仍然乖乖的，
沒鬧過什麼脾氣。

可是我會用的只有 apt-get 這個指令而己，
其它像是 dselect、aptitude 之類的懂的實在不多...
但 Debian 似乎怎麼亂搞它都不太在乎。

一個觀念，觀念要正確，然後再來
作事情，作套件的機制的目的是要達
到什麼? 沒有達到，你release出來幹
嘛?

那麼依您的看法，
您覺得 Debian 的套件機制還有什麼需要改進的地方呢？