[ON] Debian запрещает использование в пакетах секции со специфичными для вендоров патчами

[rssbot]

Технический комитет проекта Debian принял решение запретить использование специфичных для вендоров наборов патчей в пакетах (секция vendor-specific). Наличие подобных патчей в пакете теперь будет приравниваться к наличию ошибки с необходимостью её устранения. После выхода Debian 10 "Buster" использование секции vendor-specific в пакетах будет запрещено.

Комитет пришёл к заключению, что пакеты, по разному ведущие себя в разных дистрибутивах, должны распространяться в отдельных исходных пакетах. Специфичные изменения также могут применяться с использованием существующих в dpkg условных операторов или применения патчей в процессе сборки, но не на уровне подстановки разных патчей на стадии распаковки исходного пакета. В качестве причины запрета также упоминается возникновение проблем с отладкой ошибок и несовместимость с используемыми проектом инструментами для обработки патчей, такими как dgit.

Секция vendor-specific позволяет определить альтернативный набор патчей, который будет применяться при распаковке исходного пакета в других дистрибутивах (напрмер, выполнение "dpkg-source -x foo.dsc" в Debian и Ubuntu приведёт к применению разных наборов патчей к распакованным исходным текстам). Данная секция активно используется разработчиками Ubuntu для включения специфичных для Ubuntu исправлений, что позволяет поддерживать один общий пакет и для Debian и для Ubuntu. Подобный подход упрощает сопровождение производных от Debian дистрибутивов, так как не требует поддержки отдельных ответвлений пакетов с небольшими изменениями, которые можно распространять в основном Debian-пакете.

С другой стороны, на основе одного исходного пакета формируется несколько вариантов сборок, что приводит к путанице при выпуске обновлений и при разборе поступающих от пользователей уведомлений об ошибках. Обычно исходные пакеты в Debian поставляются в форме переносимых архивов (tar), разбирая подобный архив в другом дистрибутиве пользователь может полагать, что будет применён основной набор патчей, в то время как будут задействованы другие патчи из секции vendor-specific. Кроме того, в случае обновления только специфичных для вендоров патчей возникает замешательство, так как пакет не требует обновления в Debian, но при этом изменился.

Что касается отладки, она усложняется так как ошибка может проявляться только при активации дополнительных патчей, что требует определения какой вариант пакета приводит к проблеме и воссоздания условий его использования. Например, кто-то может попытаться использовать Debian для разбора ошибки в Ubuntu и загрузит для этого пакет из репозитория Ubuntu, но так как пакет общий с Debian он соберётся с другими патчами и поведение приложения будет отличаться от поведения в Ubuntu, но для разработчика это будет не очевидно.

Вместо секции vendor-specific для выделения специфичного для других дистрибутивов изменений предлагается использовать условные операторы, например, "#ifdef ubuntu". Подобные изменения видны в коде и при разборе изменений сразу позволяют понять логику применения предлагаемых исправлений. Кроме того, применение условных конструкций не создаёт проблем при использовании утилит, таких как dgit.


Источник: https://www.opennet.ru/opennews/art.shtml?num=49605
(opennet.ru, основная лента)

[Bizdelnick]

Занятно, я не знал про такую фичу. Оно, пожалуй, и к лучшему, а то ещё использовал бы где-нибудь. ☺

[serzh-z]

То есть они это уже запретили, а альтернативное решение еще не разрешили?

Не уверен, что подход "явное лучше неявного" в этом случае лучше и уж точно не добавит читабельности исходникам пакетов (или как там это в APT называется).

[Bizdelnick]

То есть они это уже запретили, а альтернативное решение еще не разрешили?

А где тут сказано про какое-то альтернативное решение, которое надо разрешать?

уж точно не добавит читабельности исходникам пакетов

Они всяко читабельностью не страдают. Но нежданчиков станет меньше, так что, наверное, оно к лучшему.

[chitatel]

Это epic win или epic fail?

[serzh-z]

А где тут сказано про какое-то альтернативное решение, которое надо разрешать?

Вместо секции vendor-specific для выделения специфичного для других дистрибутивов изменений предлагается использовать условные операторы

Это уже есть?

[/dev/random]

Это уже есть?

Это они предлагают впатчивать #ifdef'ы прямо в исходники на C и прочем, чтобы дистрибутивные секции выбирал компилятор, вместо того, чтобы на уровне пакета решать, что и как патчить в зависимости от дистрибутива.

[Bizdelnick]

Это уже есть?

Условные операторы в препроцессоре C есть полсотни лет почти.

[devilr]

Ну, условные операторы читабельности коду обычно не прибавляют. Особенно, вложенные.
Но, это гораздо удобнее, чем сторонний патч, который можно и забыть применить. Особенно, когда без него в данном дистрибутиве всё работает, а в другом - нет.

[serzh-z]

Это они предлагают впатчивать #ifdef'ы прямо в исходники на C

Жесть-то какая. Я думал, что это APT-альтернатива условных макросов в спеках RPM.

[Bizdelnick]

Я думал, что это APT-альтернатива условных макросов в спеках RPM.

К счастью, deb-based дистрибутивы ещё не настолько разнородны, как rpm-based, так что реальной потребности в этом нет. Хотя извращенцы могут вставить какую-нибудь проверку прямо в rules, никаких инноваций для этого не требуется. Условные операторы ни в make, ни в шелле не запрещали.

[serzh-z]

Но, это гораздо удобнее, чем сторонний патч

Может и удобнее, но одно дело - просто дистроспецифичные патчи, никак не влияющие на транк, и совсем другое - код, который обязан знать и поддерживать всю эту тучу форков Debian. А самое плохое, что никогда не знаешь, когда эту поддержку уже можно выбросить из кода, а когда она ещё нужна.

К счастью, deb-based дистрибутивы ещё не настолько разнородны

Не Debian ли самый форкнутый дистрибутив в мире? Неужели все эти форки настолько однородны и отличаются лишь картинками?

[Bizdelnick]

Не Debian ли самый форкнутый дистрибутив в мире?

RPM-based дистрибутивы не являются форками какого-то одного. А дебиановские форки недофоркнутые, они время от времени синхронизируют с ним пакетную базу.

[chitatel]

Почитал форумчан, пришёл к выводу, что это в целом epic win, с таким привкусом epic fail.

Ну или epic fail, но где-то там глубоко внутри - epic win.

[serzh-z]

chitatel
Это не вин и не фейл. Просто иначе, чем было. )