Parallel


Original: http://ometer.com/parallel.html

Гэта было напісана ў студзені 2002 году

Гэта кароткае кіраўніцтва да таго , як і чаму , каб зрабіць несумяшчальныя версіі бібліятэк і сродкаў распрацоўкі ўсталяваць паралельна. І праблема вырашаецца , і раствор заснаваныя на практычным вопыце работы на GNOME і Red Hat Linux ; так што спадзяюся , у мяне ёсць больш, каб сказаць , чым проста спекуляцыі.

Калі два пакеты могуць быць паралельнымі усталяваны , то ў іх няма імёнаў файлаў у агульным , і людзі , якія развіваюцца супраць пакета заўсёды атрымаць версію яны чакалі. Акрамя таго , пакеты прызначаны для нармальна суіснаваць , калі ў іх ёсць якія-небудзь асаблівасці падчас выканання , напрыклад , дэманаў або канфігурацыйныя файлы.

Праблема

Давайце возьмем просты прыклад. Скажам , у вас ёсць бібліятэка з імем Foo , і калекцыю праграмных пакетаў у вашым WayCool Linux Размеркаванне тыдня ( WCLDW ) . Бібліятэка Foo мае два часта выкарыстоўваюцца несумяшчальныя версіі 4 і 5 . Некаторыя з пакетаў для WCLDW выкарыстання версіі 4 уверх па плыні , і некаторыя выкарыстоўваюць версіі 5 .

На жаль , толькі адна версія Foo могуць быць выбраны. Так распрацоўшчыкі WCLDW стаіць задача партавання палову сваіх пакетаў на іншай версіі . Негатыўны ўплыў гэтай партавання працы:

Гэта можа быць вельмі шмат працы для вельмі невялікай колькасці бачнага карыстачу выгады.
Ён спараджае ўсе гэтыя пакеты з уверх па плыні , ўскладнення працэдуры для справаздач аб памылках і выпраўленняў.
Калі некаторыя з пакетаў , якія залежаць ад Foo самі бібліятэкі , і яны перанесены на новы Foo , то SONAME на бібліятэках павінен быць павялічаны , якая разыходзіцца з SONAME ад здабычы на ўсю вечнасць (так як кожны перад SONAME ўдар давядзецца быць адпавядае іншым размеркавання SONAME удар) .
Уверх па плыні разыходжанне вынікаў у розных дыстрыбутываў быць двайковы несумяшчальныя адзін з адным , перамогшы мэтаў нешта накшталт LSB .
Партаванне усё на новы Foo можа зрабіць новая версія WCLDW несумяшчальнай з яго старымі версіямі .

У выніку многія дыстрыбутывы прыняць спецыяльныя метады ўстаноўкі двух версій Foo у размеркавальных спецыяльных латак , як меншае зло , чым вышэй спіс негатываў.

Праблема тут заключаецца не толькі ў Linux (або іншых АС ) размеркаванняў , аднак. Гэта таксама з’яўляецца праблемай для суправаджалых многіх адзіночных праграмных пакетаў , а таксама для праектаў , якія складаюцца з многіх пакетаў (напрыклад , GNOME ці KDE). Яшчэ некалькі пытанняў:

У суправаджальніка пакета , калі я не ведаю , што я атрымаю ў выніку “ # ўключыць “ ці “ – lfoo “ , я атрымліваю шмат памылак паведамленнях з заблытаных карыстальнікаў , паколькі яны ўвесь час спрабуюць выкарыстоўваць няправільны Foo .
Калі людзі прымудраюцца скласці не да той Foo , і я атрымліваю паведамленні пра памылкі, гэта беспарадак , калі карыстальнікі адчуваюць памылка супраць Foo , які мае розную семантыку ад Foo я выкарыстоўваю .
Размеркавання маюць тэндэнцыю ствараць нерэгламентыраваным спосабы вырашэння двух версій Foo , што азначае , што з Makefile і наладзіць скрыпты павінны спецыяльнага выпадку гэтыя размеркавання. Гэта значна лепш , калі уверх па плыні праекты вырашэння праблемы самі.
Для буйных праектаў , такіх як GNOME , і адказныя за 50 + пакетаў ўсе павінны змяніць Foo версіі ў той жа час. Абнаўленне Foo можа патрабаваць ад людзей , каб выдаліць Foo неабходныя для ўсіх пакетаў у іх размеркаванні . Гэта прыводзіць да вялікай колькасці нежаданне перайсці ад Foo 4 да Foo 5 .
Карыстальнікі аперацыйных сістэм або размеркаванняў з няправільнай Foo усталяванай не можа ўсталяваць маю праграму , без выдалення праграмнага забеспячэння OS , якая патрабуе іншай Foo . Так мая аўдыторыя абмежавана – Я павінен спытаць людзей адмовіцца ад некаторых з іх бягучай версіі праграмнага забеспячэння , каб атрымаць мой новае праграмнае забеспячэнне .

Рашэнне

Рашэнне праблемы , па сутнасці , перайменаваць Foo , і ў большасці выпадкаў самы добры спосаб зрабіць так , каб уключыць нумар версіі ў імя кожнага файла. Гэта азначае , абедзве версіі Foo можа быць усталяваны ў той жа час.

Напрыклад , кажуць , што Foo традыцыйна ўключае ў сябе наступныя файлы :

/ USR / ўключаць / foo.h
/ USR / Бібліятэка / libfoo.so
/ USR / долі / DOC / Foo / Foo – Manual.txt
/ USR / бен / foolizer

Вы можаце змяніць Foo версіі 4 , каб уключыць гэтыя файлы , а ня :

/ Usr/include/foo-4/foo.h
/ Usr/lib/libfoo-4.so
/ Usr/share/doc/foo-4/foo-manual.txt
/ Usr/bin/foolizer-4

і Foo версіі 5 у тым ліку:

/ Usr/include/foo-5/foo.h
/ Usr/lib/libfoo-5.so
/ Usr/share/doc/foo-5/foo-manual.txt
/ Usr/bin/foolizer-5

Цяпер людзі проста паказаць, якія Foo яны хочуць , у той жа час яны павінны паказаць , што яны хочуць Bar замест Foo – з дапамогай іншага імя бібліятэкі.

Для GNOME , мы выкарыстоўваем PKG – канфігурацыі , каб зрабіць гэта больш зручным для распрацоўнікаў прыкладанняў. уп – канфігурацыі істотна абстрагуюцца імя бібліятэкі («- lfoo – 4″) і ўключаюць у сябе размяшчэнне файла ( “ -I/usr/include/foo-4 “ ) , так што распрацоўнікам прыкладанняў не трэба жорстка задаць гэтыя рэчы ў іх ужыванні . уп – канфігурацыі асобная ўтыліта без залежнасцяў GNOME , так што кожны можа выкарыстоўваць яго і некаторыя пакеты ўжо робяць.

Звярніце ўвагу , што нумары версій у імёнах файлаў Foo з’яўляюцца не колькасць поўная версія Foo . Як мяркуецца, Foo 4.0.1 , 4.0.2 , 4.0.3 , далей , усё існуе , а тыя , будзе Выпраўленне памылкі выкідаў у серыі Foo 4 і ўсе яны маюць адзін і той жа API і ABI . Так як яны з’яўляюцца ўзаемазаменнымі , няма ніякай неабходнасці , каб перайменаваць што-небудзь , калі яны выходзяць. Усе Выпраўленне – толькі сумяшчальныя рэлізы павінны выкарыстоўваць той жа імя бібліятэкі.
Ліквідацыю бар’ераў для новай версіі прыняцця

Вялікім перавагай паралельнага мантажу з’яўляецца тое , што вы выдаліце ​​прычына , чаму людзі неахвотна перайсці на новую версію Foo , таму абнаўлення да Foo 5 не мае ніякага ўплыву на карыстальнікаў Foo 4 . Гэта азначае , што пакеты ў WCLDW можна павялічыць з дапамогай іх зыходнага ПА , па адным за раз. Гэта азначае , што пакеты GNOME можна абнавіць да Foo 5 па адным. Гэта азначае , што , калі я выкарыстоўваю тэкставы рэдактар ​​у залежнасць ад Foo 4, але хачу , каб мой пакет выкарыстоўваць Foo 5 , я магу зрабіць гэта , так як я магу ўсталяваць абедзве версіі Foo у той жа час.

Карацей кажучы , паралельна ўсталяваць ядзерную зброю праблему курыцы і яйкі , і гэта эканоміць кожнаму кучу часу і энергіі.

( Пабочны эфект : раптам у вас ёсць значна больш свабоды , каб зламаць зваротную сумяшчальнасць ; ваш новы несумяшчальнай версіі , на самай справе іншая бібліятэка , не тое ж самае бібліятэка Так што калі вам трэба ачысціць вялікую гняздо хламу , не склала вялікай працы Не .. мы вымушаныя абнавіць , пакуль яны не маюць часу займацца з абрыву . )
тэарэтычная выгляд

Там у шлях , больш высокага ўзроўню , каб растлумачыць , чаму паралельна ўсталяваць гэта правільна. Вось проста так: праграмы , якія запытваюць функцыянальнасць павінна атрымаць тое , што яны мелі намер атрымаць .

Функцыянальнасць звычайна прасіў па імені , ці з’яўляецца імя гэтае імя функцыі , імя выкананага файла або імя каталога .

Такім чынам , імёны павінны сапраўды зменіцца , калі назваў рэч становіцца іншым , гэта значыць калі яна становіцца несумяшчальныя. Калі імёны часцей мяняць , чым , праграмы , якія запытваюць функцыянальнасць будзе не ў стане атрымаць яго , калі яны маглі б мець. Калі імёны змяніць радзей , праграмы , якія запытваюць функцыянальнасць атрымаеце няправільныя функцыянальнасць і непаладках у працы .
Інфармацыя аб рэалізацыі

У гэтым раздзеле разглядаюцца некаторыя агульныя пытанні , якія ўзнікаюць пры рэалізацыі паралельную ўстаноўку.

Калі рабіць перайменаванне

Вы можаце пайсці далей і ўключыць “ 4″ у імя файла кожнага файла foo4 з самага пачатку , ці вы можаце чакаць , пакуль Foo5 не будзе адпушчаная , затым адпусціце foo4 які мае файлы перамешчаныя. Маё меркаванне такое , што былы ( зрабіць foo4 з версіямі з самага пачатку) прасцей для ўсіх , але другі падыход працуе , калі вы не планавалі для паралельнай інсталяцыі ў мінулым.
Што такое “ нумар версіі“ для мэт перайменавання ?

Нумар версіі , якая ідзе ў імёнах файлаў з’яўляецца “ Абі / API “ версія. Яна не павінна быць колькасць поўная версія пакета . Напрыклад , GTK + 1.2.9 , 1.2.10 , 1.2.11 з’яўляюцца цалкам API / ABI сумяшчальныя , таму яны не ўстаноўлены паралельна. Тым не менш , GTK + 1.2.x і 2.0.x не сумяшчальныя , таму яны ўстаноўлены паралельна. Іх імёны файлаў ўтрымліваюць “ 1.2 “ і “ 2.0 “ адпаведна , а не “ 1.2.10 “ ці “ 2.0.3 “ .

Карацей кажучы , любая “ выпраўлення толькі “ сумяшчальная рэліз не запатрабуе перамяшчэння ўсіх файлаў.
файлы загалоўкаў

Файлы загалоўкаў заўсёды павінен быць усталяваны ў версированной падкаталогу , які патрабуе -I сцяг кампілятара C. Напрыклад , калі мой загаловак foo.h і прыкладанняў гэтага :

# Уключыць

то я павінен ўсталяваць гэтыя файлы :

/ Usr/include/foo-4/foo.h
/ Usr/include/foo-5/foo.h

і дадатку павінны перадаць сцяг -I/usr/include/foo-4 або -I/usr/include/foo-5 для кампілятара C. Зноў жа , гэта спрыяе дапамогай PKG – канфігурацыі.

Лепшая практыка паказвае , што Foo прыкладання павінны быць сапраўды у тым ліку “ Нехта / foo.h “ :

# Уключыць <foo/foo.h>

таму што гэта прастора імёнаў па # уключыць, каб пазбегнуць сутыкненняў з іншымі бібліятэкамі. У гэтым выпадку Foo павінны ўсталяваць :

/ Usr/include/foo-4/foo/foo.h
/ Usr/include/foo-5/foo/foo.h

Вы таксама можаце проста перайменаваць сам загаловак :

/ Usr/include/foo-4.h

Але падыход каталог прыемней , так як распрацоўшчыкі прыкладанняў павінны толькі змяніць адзін -I сцяг , а не ўсе іх ўключаюць заявы , калі яны абнавіць .

Там-то спакуса трымаць адзін з файлаў загалоўкаў за межамі любой падкаталог :

/ USR / ўключаць / foo.h
/ Usr/include/foo-5/foo.h

Праблема ёсць , што карыстальнікі заўсёды выпадкова атрымаць няправільны загаловак , так як “ -I/usr/include “ , здаецца , знайсці свой ​​шлях на кампіляцыі ліній каманд з некаторай рэгулярнасцю . Калі вы павінны зрабіць гэта , па меншай меры , дадаць праверку ў бібліятэку , якая выяўляе прыкладання , выкарыстоўваючы файл загалоўка не так , калі бібліятэка ініцыялізуецца .

Бібліятэкі

Бібліятэка аб’ектных файлаў павінны мець версированный імя. Напрыклад :

/ Usr/lib/libfoo-4.so
/ Usr/lib/libfoo-5.so

Гэта дазваляе прыкладанням атрымаць менавіта тую , якую яны хочуць падчас кампіляцыі , і гарантуе , што Foo 4 і Foo 5 няма файлаў агульнага.

Чаму не бібліятэка sonames дастаткова добра ?

Бібліятэка sonames толькі вырашыць праблему выканання якая злучае раней скампіляваныя прыкладання. Яны не датычацца пытання аб кампіляцыі прыкладанняў , якія патрабуюць папярэднюю версію , і яны нічога , акрамя бібліятэк не звяртаўся.
файлы канфігурацыі

З пункту гледжання карыстальніка , лепшым падыходам да файлаў налад , каб захаваць фармат і наперад і назад сумяшчальны ( абедзве версіі бібліятэкі зразумець дакладна такія ж сінтаксічныя канфігурацыйны файл / семантыку ) .

Калі вы не можаце зрабіць гэта , файлы канфігурацыі проста павінен быць перайменаваны , і карыстальнікам прыйдзецца наладжваць кожны версію бібліятэкі асобна.
Gettext пераклады

Калі вы выкарыстоўваеце Gettext для перакладаў у спалучэнні з AUTOCONF / Automake , звычайна ўсё настроены ўсталяваць пераклады / USR / долі / лакалізацыі / / LC_MESSAGES / . Вы павінны будзеце змяніць ўдзел . Канвенцыя мы выкарыстоўваем у GNOME гэта паставіць гэта ў configure.in :

GETTEXT_PACKAGE = foo4
AC_SUBST ( GETTEXT_PACKAGE )
AC_DEFINE_UNQUOTED ( GETTEXT_PACKAGE , „$ GETTEXT_PACKAGE “ )

Затым з дапамогай GETTEXT_PACKAGE якасці імя пакета , каб перайсці да bindtextdomain ( ) , маёнткаў ( ) , і / або dgettext ( ) .

Іншыя залежнасці часу выканання

Калі ваш пакет уключае ў сябе дэманаў , IPC і г.д. , то вы , магчыма , прыйдзецца прыдумаць больш складаных рашэнняў па гэтых пытаннях.
Калі гэта ўжыць да прыкладанняў , а не толькі бібліятэк і раз інструменты ?

Гэта значна менш важным , таму што абнаўленне прыкладання не маюць наступствы для мадэрнізацыі іншых пакетаў у той жа сістэме . Аднак калі ваша прыкладанне выкарыстоўваецца іншымі праграмамі , у якасці кампанента , магчыма , яна цалкам можа мець сэнс , а так як ваша прыкладанне эфектыўна інструментам развіцця або API ў гэтай кропцы.
Хіба не ўсе гэтыя файлы пад кантролем версій роду выродлівыя ?

Магчыма , але гэта здаецца дурным , каб зрабіць працу для ўсіх , стварыць праблемы сумяшчальнасці паміж аперацыйнымі сістэмамі , і перашкаджаць прыняццю новых версій , чыста з эстэтычных меркаванняў.

Паралельна ўсталяваць сапраўды лёгка рэалізаваць і робіць жыццё лепш для карыстальнікаў , для дыстрыбутыва , для распрацоўнікаў прыкладанняў , якія выкарыстоўваюць вашу бібліятэку , і нават для вас , як бібліятэкі суправаджальніка .

Ён таксама мае доўгую гісторыю як правільна рабіць , напрыклад COM праграмісты будуць знаёмыя з прынцыпам , што ўсе інтэрфейсы павінны быць перайменаваны ў выпадку іх змены .

Ці ёсць альтэрнатыўныя падыходы ?

Адзіны рэальны альтэрнатыўны падыход я ведаю , каб пазбегнуць парушэнні сумяшчальнасці , ніколі. Гэта тое , што стандартная бібліятэка C робіць , напрыклад.
А як наконт сімвала версіямі ?

Сімвал версій на самай справе не ці / або з паралельным ўстаноўкі дактрыны я абараняю тут. Дактрына з’яўляецца “ , калі вы парушыце зваротную сумяшчальнасць , неабходна перайменаваць. “ Сімвал версій з’яўляецца спосабам пазбегнуць парушэнні зваротнай сумяшчальнасці. Паралельна ўсталяваць гэта спосаб мінімізаваць ўздзеянне парушаючы зваротную сумяшчальнасць . Так што калі вы выкарыстоўваеце сімвал версіямі вы можаце ніколі не трэба перайменаваць нічога .

На больш практычным узроўні , сімвал версіі не партатыўная рашэнне , якое спыніць усю працу для многіх праектаў.

Дзе я магу знайсці некалькі прыкладаў ?

Усе платформы паралельна GNOME 2 устанаўліваецца з платформай GNOME 1 . Акрамя таго , libxml1 і libxml2 раўналежныя усталяваны ў апошніх версіях ; LibXML цікавы тым , што ён часта выкарыстоўваецца на АС Windows , а таксама. Глядзець GNOME і LibXML . (Калі ў каго ёсць яшчэ прыклады пошце [email protected] )

Comments are closed.