[devel] apt-conf-branch и apt-conf-sisyphus

[devel] apt-conf-branch и apt-conf-sisyphus

[Leonid Krivoshein]

По мотивам багов #34510 и #30806, которые теперь точно можно закрыть.

Мне кажется, у нас небольшая проблема. Надеюсь, решаемая. Речь о 
пакетном наполнении образов, собираемых mkimage. Сам он, как оказалось, 
не причём, это особенность APT'а и следствие mkimage-profiles. Ну и, 
конечно, наша традиция использовать ВЕЗДЕ одинаковые 
/etc/apt/pkgpriorities из apt-conf-{branch,sisyphus}, точнее, не 
использовать их по назначению ВООБЩЕ. Но, давайте по-порядку...

В mate-default была приколочена жёсткая зависимость на firefox. Это 
мешало сделать специальную сборку с firefox-gost, поэтому баг закрыли, 
поменяв зависимость на webclient. На последних регулярках в сборку с 
MATE стал приезжать браузер rekonq, ко всему прочему нерабочий. Понятное 
дело, тащил он за собой кучу всего Qt'шного и KDE'шного. А главное, 
причину искали долго, поскольку бага очевидно затрагивала не только 
регулярки, но и почти все наши основные дистрибутивы с MATE.

Причиной оказалась в зависимости xsane от webclient. Если ставить так:

apt-get install xsane firefox

То в систему попадает ещё и rekonq. А если так:

apt-get install firefox xsane

То не попадёт. То есть, от перемены мест слагаемых наполнение 
дистрибутивного образа явно зависит, причём так работает наш apt. 
Регулировать порядок следования пакетов в финальном списке, формируемом 
в m-p и передаваемом mki, на мой взгляд, чересчур проблематично. Но 
подобных сторонних эффектов мы ещё встретим много, если не поменяем 
подход к /etc/apt/pkgpriorities (у APT'а есть ещё PIN-priorities). При 
помощи этой штуки регулировать предпочтения для того или иного 
дистрибутива правильней, тогда и коллизий подобных станет на порядок 
меньше. В нашем случае для дистрибутивов с MATE и Firefox:

echo "  firefox" >> /etc/apt/pkgpriorities
apt-get install xsane firefox

Теперь без разницы, на каком месте xsane. Костыль, конечно. Но править 
логику apt'а будет сложнее...


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] apt-conf-branch и apt-conf-sisyphus

[Sergey V Turchin]

On Wednesday, 21 February 2018 03:01:37 MSK Leonid Krivoshein wrote:
> По мотивам багов #34510 и #30806, которые теперь точно можно закрыть.
> 
> Мне кажется, у нас небольшая проблема.
У вас.

> Надеюсь, решаемая.
Я просто помещаю пакеты, разрешающие виртуальные зависимости, ближе к началу 
списка и в ус не дую.

[...]

-- 
Regards, Sergey.

Re: [devel] apt-conf-branch и apt-conf-sisyphus

[Leonid Krivoshein]

22.02.2018 10:44, Sergey V Turchin пишет:
>> Надеюсь, решаемая.
> Я просто помещаю пакеты, разрешающие виртуальные зависимости, ближе к началу
> списка и в ус не дую.

Это тоже костыль. Тем более, не во всех случаях легко реализуемый 
средствами m-p или согласно его духу. Сейчас вы обладаете знаниями, из 
какого списка какие пакеты пойдут в первую очередь и помещаете 
виртуальные зависимости в него. Потом меняется mkimage или логика работы 
m-p (одной из фич), и ваши ожидания не оправдаются. От порядка 
следования пакетов вообще ничего не должно зависеть. Именно поэтому 
предлагается в mkimage добавить сортировку перед передачей 
окончательного списка APT'у. В том числе, чтоб избежать взаимного 
влияния фич на редко меняющиеся профили, когда такой разъезд можно 
словить спустя 1.5-3 года.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] apt-conf-branch и apt-conf-sisyphus

[Sergey V Turchin]

On Thursday, 22 February 2018 11:09:30 MSK Leonid Krivoshein wrote:
> 22.02.2018 10:44, Sergey V Turchin пишет:
> >> Надеюсь, решаемая.
> > 
> > Я просто помещаю пакеты, разрешающие виртуальные зависимости, ближе к
> > началу списка и в ус не дую.
> Это тоже костыль. Тем более, не во всех случаях легко реализуемый
> средствами m-p или согласно его духу.
Я не испытывал особых сложностей на протяжении многих лет.

> Сейчас вы обладаете знаниями, из
> какого списка какие пакеты пойдут в первую очередь и помещаете
> виртуальные зависимости в него.
Да. Мантейнер дистрибутива должен хоть какими-то знаниями обладать.
Идея, когда любая домохозяйка может всыпать мешок пакетов в mkimage и на 
выходе получить дистрибутив, оказалась сложнореализуемой.

> Потом меняется mkimage
Еще apt и rpm.

> или логика работы m-p (одной из фич)
У меня менялся весь m-p на "очень другой". Boyarsh@, например, на старом 
остался.

> , и ваши ожидания не оправдаются. 
Оправдались. Уже.

> От порядка следования пакетов вообще ничего не должно зависеть.
Это теория. У нас установка идёт в несколько транзакций.

> Именно поэтому
> предлагается в mkimage добавить сортировку перед передачей
> окончательного списка APT'у. В том числе, чтоб избежать взаимного
> влияния фич на редко меняющиеся профили,
Mike@, как как наиболее сталкивающийся с подобными ситуациями, вам расскажет, 
что никакая сортировка не поможет от изменения набора и свойств пакетов(моих, 
например ;-) ) в репозитории.

> когда такой разъезд можно словить спустя
> 1.5-3 года.
Слабовата ваша способность предсказывания. ;-)

-- 
Regards, Sergey.

Re: [devel] apt-conf-branch и apt-conf-sisyphus

[Paul Wolneykien]

22.02.2018 11:56, Sergey V Turchin пишет:
>> От порядка следования пакетов вообще ничего не должно зависеть.
> Это теория. У нас установка идёт в несколько транзакций.

  От порядка следования пакетов в транзакции. Я думаю, что нужно править
apt, а не нашлёпку сверху.

Re: [devel] apt-conf-branch и apt-conf-sisyphus

[Leonid Krivoshein]

22.02.2018 11:56, Sergey V Turchin пишет:
> On Thursday, 22 February 2018 11:09:30 MSK Leonid Krivoshein wrote:
>> 22.02.2018 10:44, Sergey V Turchin пишет:
>>>> Надеюсь, решаемая.
>>> Я просто помещаю пакеты, разрешающие виртуальные зависимости, ближе к
>>> началу списка и в ус не дую.
>> Это тоже костыль. Тем более, не во всех случаях легко реализуемый
>> средствами m-p или согласно его духу.
> Я не испытывал особых сложностей на протяжении многих лет.
>
>> , и ваши ожидания не оправдаются.
> Оправдались. Уже.

Настоящая история успеха, буду теперь её внукам рассказывать! Не каждому 
дано, выбирая не самый простой и очевидный путь, за столько лет ни разу 
не схлопотать неприятностей от такого выбора. :)

>> От порядка следования пакетов вообще ничего не должно зависеть.
> Это теория. У нас установка идёт в несколько транзакций.

В build-image их две: базовая система (initial packages) и всё 
остальное. Потом отдельные пакеты могут до-устанавливаться, но, если не 
изменяет память, это уже не build-image, а другая цель. Фактически, все 
пакеты, имеющие виртуальные зависимости и чувствительные к обсуждаемой 
ситуации, ставятся в одну большую транзакцию. Мы тоже были уверены, что 
это не так, что это лажа mkimage из-за разделения списков, по крайней 
мере, на две части -- с regex'ами и без, поэтому тщательно всё 
перепроверили, прежде чем обозначить виновника.

>> Именно поэтому
>> предлагается в mkimage добавить сортировку перед передачей
>> окончательного списка APT'у. В том числе, чтоб избежать взаимного
>> влияния фич на редко меняющиеся профили,
> Mike@, как как наиболее сталкивающийся с подобными ситуациями, вам расскажет,
> что никакая сортировка не поможет от изменения набора и свойств пакетов(моих,
> например ;-) ) в репозитории.

От этого не поможет, но сортировка нужна не для этого. Уверен, со 
многими полтергейстами вокруг m-p, которым раньше не могли найти 
объяснений,  после добавления сортировки или исправление apt'а будет 
покончено.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] apt-conf-branch и apt-conf-sisyphus

[Sergey V Turchin]

On Friday, 23 February 2018 00:26:10 MSK Leonid Krivoshein wrote:

[...]
> Настоящая история успеха, буду теперь её внукам рассказывать!
Да что там! Архивы рассылки будете перед сном читать. ;-)

> Не каждому дано,
Но, многим. ;-)

> выбирая не самый простой и очевидный путь, за столько лет ни разу
> не схлопотать неприятностей от такого выбора. :)

[...]
> В build-image их две: базовая система (initial packages) и всё
> остальное. Потом отдельные пакеты могут до-устанавливаться, но, если не
> изменяет память, это уже не build-image, а другая цель. Фактически, все
> пакеты, имеющие виртуальные зависимости и чувствительные к обсуждаемой
> ситуации, ставятся в одну большую транзакцию. Мы тоже были уверены, что
> это не так, что это лажа mkimage из-за разделения списков, по крайней
> мере, на две части -- с regex'ами и без, поэтому тщательно всё
> перепроверили, прежде чем обозначить виновника.
Уже проверили и даже перепроверили или только теория?

[...]
> От этого не поможет, но сортировка нужна не для этого. Уверен, со
> многими полтергейстами вокруг m-p, которым раньше не могли найти
> объяснений,  после добавления сортировки или исправление apt'а будет
> покончено.
Я уверен, что это обмен шила на мыло. Виртуальные пакеты таковыми и останутся.

-- 
Regards, Sergey.