Вопрос о зависимостях между пакетами в случае обновления только некой части пакетов.
В рамках изучения вопроса назначения версий программным проектам я прочел: file:///usr/share/doc/debian-policy/policy-1.html#ch-relationships (Chapter 7 - Declaring relationships between packages) У меня возник вопрос как правильно описать зависимости в таком случае: * foo (3.4) зависит от bar (= 1.3). * Появляется новая версия bar (2.1, допустим с выходом нового релиза Debian), которая ломает обратную совместимость с предыдущей версией (серии 1.x). Как описать зависимости что бы гарантировать работоспособность foo (т.е. рекомендовать обновить или удалить foo)? Например в рамках нового релиза Debian тестированием можно выявить несовместимость и в новом пакете bar написать: Breaks: foo (= 3.4) Но тестирование еще нужно выполнить или ожидать баг-репортов. Да и правильно ли перечислять все сторонние пакеты, которые используют данный пакет? От релиза к релизу 'Breaks' будет распухать от описаний устаревших пакетов. -- Best regards! -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j57tl2$atb$1...@dough.gmane.org
Зачем нужна компонента [debian_revision]?
Согласно [1] компонента [debian_revision] отражает изменения от проекта Debian по отношению к оригинальному пакету. Как я понимаю [debian_revision] инкрементируется в случае бакфикса (включая секурити-фикс). Является ли этот параметр признаком необходимости обязательно обновить пакет или инкремент также описывает некритичные изменения (как то поправлена лицензия, допилено окошко GUI, ну в общем функционирование старой версии не разрушает пользовательских данных)? Применяется ли практика, подобная в системе rpm [2]: The release tag is usually incremented every time a package is rebuilt for any reason, even if the source code does not change Так, выход Debian 6.0.2 не потребовал обновления *всех* установленных пакетов от Debian 6.0.1... [1] file:///usr/share/doc/debian-policy/policy-1.html#s-f-Version (5.6.12 Version) [2] http://www.rpm.org/wiki/PackagerDocs/Dependencies#RequiringPackages -- Best regards! -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j57unh$iap$1...@dough.gmane.org
Re: Вопрос о зависимостях между пакетами в случае обновления только некой части пакетов.
В Mon, 19 Sep 2011 20:20:29 +0300 Oleksandr Gavenko gaven...@gmail.com пишет: В рамках изучения вопроса назначения версий программным проектам я прочел: file:///usr/share/doc/debian-policy/policy-1.html#ch-relationships (Chapter 7 - Declaring relationships between packages) У меня возник вопрос как правильно описать зависимости в таком случае: * foo (3.4) зависит от bar (= 1.3). * Появляется новая версия bar (2.1, допустим с выходом нового релиза Debian), которая ломает обратную совместимость с предыдущей версией (серии 1.x). Как описать зависимости что бы гарантировать работоспособность foo (т.е. рекомендовать обновить или удалить foo)? Например в рамках нового релиза Debian тестированием можно выявить несовместимость и в новом пакете bar написать: Breaks: foo (= 3.4) Но тестирование еще нужно выполнить или ожидать баг-репортов. Да и правильно ли перечислять все сторонние пакеты, которые используют данный пакет? От релиза к релизу 'Breaks' будет распухать от описаний устаревших пакетов. Скорее, в foo надо написать bar (2.1). -- Best Regards, Yuri Kozlov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110919220627.2447f...@keeper.home.local
Re: dd
On 08/30/11 21:56, Sergey Korobitsin wrote: Ivan Petrov ☫ → To debian-russian@lists.debian.org @ Wed, Aug 31, 2011 00:43 +0700 Можно ли просмотреть файлы с dd образа линуксового раздела и извелечь нужный? kpartx -av disk.img mount /dev/mapper/loopXXX /mnt/partition1 Как-то так. несмотря на некоторое предубеждение к программам, название которых начинается на k, я погуглил... оказывается это небольшая консольная программка ;) PS: и всё-таки вопрос был про образ раздела, а не диска... хотя я иногда имею дело с образами дисков, так что программка пригодится, спасибо. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e7788af.3020...@yandex.ru
Re: Зачем нужна компонента [debian_revision]?
Oleksandr Gavenko gaven...@gmail.com writes: Согласно [1] компонента [debian_revision] отражает изменения от проекта Debian по отношению к оригинальному пакету. Как я понимаю [debian_revision] инкрементируется в случае бакфикса (включая секурити-фикс). Является ли этот параметр признаком необходимости обязательно обновить пакет или инкремент также описывает некритичные изменения (как то поправлена лицензия, допилено окошко GUI, ну в общем функционирование старой версии не разрушает пользовательских данных)? Этот суффикс увеличивается (в «лексикографическом» порядке) каждый раз, когда требуется, чтобы система считала новый пакет обновлением к прежнему. IOW, по большему счету, при каждой пересборке, вне зависимости от степени серьезности вносимых изменений. Что касается порядка, то здесь есть некоторые особенности. E. g., если находящаяся в testing (unstable) версия 1.2-4 содержит, по отношению к версии 1.2-3 в stable, изменения, которые не планируется переносить в последний, то исправления для 1.2-3 окажутся в пакете с версией, подобной 1.2-3+stable1. Подобным образом формируется номер версии и в случае NMU. Для backports (пакетов из testing, собранных в окружении stable), номер версии будет подобен 1.2-4~backport-1, который считается системой меньшим, чем 1.2-4. Таким образом, при переходе на следующую версию Debian, backport 1.2-4~backport-1 будет заменен на «родной» пакет 1.2-4. Применяется ли практика, подобная в системе rpm [2]: The release tag is usually incremented every time a package is rebuilt for any reason, even if the source code does not change AIUI, версия собранного пакета как правило наследуется от пакета с исходным кодом. Впрочем, бывают и исключения, причины которых мне в точности не известны. Так, выход Debian 6.0.2 не потребовал обновления *всех* установленных пакетов от Debian 6.0.1... Более того, некоторые пакеты не потребовали бы обновления даже при переходе с 5.0 до 6.0. E. g., ascii имеет версию 3.8-4 как в lenny, так и в wheezy. IOW, выход версии Debian не предполагает пересборки всех без исключения пакетов. [1] file:///usr/share/doc/debian-policy/policy-1.html#s-f-Version (5.6.12 Version) [2] http://www.rpm.org/wiki/PackagerDocs/Dependencies#RequiringPackages -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86pqiwnyhs@gray.siamics.net
Re: Вопрос о зависимостях между пакетами в случае обновления только некой части пакетов.
On Mon, Sep 19, 2011 at 08:20:29PM +0300, Oleksandr Gavenko wrote:
В рамках изучения вопроса назначения версий программным проектам
я прочел:
file:///usr/share/doc/debian-policy/policy-1.html#ch-relationships
(Chapter 7 - Declaring relationships between packages)
У меня возник вопрос как правильно описать зависимости в таком случае:
* foo (3.4) зависит от bar (= 1.3).
* Появляется новая версия bar (2.1, допустим с выходом нового релиза
Debian), которая ломает обратную
совместимость с предыдущей версией (серии 1.x).
Как описать зависимости что бы гарантировать работоспособность foo
(т.е. рекомендовать обновить или удалить foo)?
Если bar -- по сути shared library, а foo с ней линкуется, то
${shlibs:Depends} сделает все как нужно.
У bar при смене soname (поломке обратной совместимости) должно полностью
меняться имя пакета. Плюс новый не должен пересекаться со старым по
файлам. Это позволяет иметь установленными две версии libbar, пока весь
софт не переедет на новую
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
--
WBR, Dmitry
signature.asc
Description: Digital signature
Re: Зачем нужна компонента [debian_revision]?
19.09.2011 23:06, Ivan Shmakov пишет: ... обновлением к прежнему. IOW, по большему счету, при каждой ... Подобным образом формируется номер версии и в случае NMU. ... AIUI, версия собранного пакета как правило наследуется от пакета ... IOW, выход версии Debian не предполагает пересборки всех без ... Ты в реальной жизни тоже сокращениями постоянно выражаешься? Ну противно ведь читать в каждом абзаце. -- Best regards, Mikhail. signature.asc Description: OpenPGP digital signature
