[devel] RFC: Merge noarch repo with arch repos

[devel] RFC: Merge noarch repo with arch repos

[Vladimir D. Seleznev]

По мотивам багрепорта #38919 [1].

Рост числа поддерживаемых архитектур, а также утрачивание поддержки
32-хразрядных архитектур апстримами, увеличили сложность отношений между
пакетами. Так как, например, скриптам-обёрткам над утилитами совсем не
нужно быть архитектурно-зависимыми, зависимость noarch-пакетов на
arch-пакеты является валидной, но сейчас всё больше noarch-пакетов
фактически становятся архитектурно-зависимыми из-за порождаемых анметов,
причины которых описаны в начале.

Разрешить эту проблему можно отказавшись от обособленного
noarch-репозитория; собранные же noarch-пакеты хардлинкать в
arch-репозитории кроме тех, в которых присутствие этих пакетов порождает
анметы.

[1] https://bugzilla.altlinux.org/show_bug.cgi?id=38919

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] RFC: Merge noarch repo with arch repos

[Anton Farygin]

Тогда уж проще отказаться от такого понятия, как noarch.

Хардлинки сэкономят только место, но при этом создадут массу других 
проблем тем, кто зеркалит.

А чем плохи симлинки ? Мы же всё равно симлинкаем в архитектуры пакеты 
из files. Пусть files остаётся как noarch, а симлинки идут в архитектуру.

On 10.09.2020 19:16, Vladimir D. Seleznev wrote:
> По мотивам багрепорта #38919 [1].
>
> Рост числа поддерживаемых архитектур, а также утрачивание поддержки
> 32-хразрядных архитектур апстримами, увеличили сложность отношений между
> пакетами. Так как, например, скриптам-обёрткам над утилитами совсем не
> нужно быть архитектурно-зависимыми, зависимость noarch-пакетов на
> arch-пакеты является валидной, но сейчас всё больше noarch-пакетов
> фактически становятся архитектурно-зависимыми из-за порождаемых анметов,
> причины которых описаны в начале.
>
> Разрешить эту проблему можно отказавшись от обособленного
> noarch-репозитория; собранные же noarch-пакеты хардлинкать в
> arch-репозитории кроме тех, в которых присутствие этих пакетов порождает
> анметы.
>
> [1] https://bugzilla.altlinux.org/show_bug.cgi?id=38919
>

Re: [devel] RFC: Merge noarch repo with arch repos

[Vladimir D. Seleznev]

On Thu, Sep 10, 2020 at 07:22:08PM +0300, Anton Farygin wrote:
> Тогда уж проще отказаться от такого понятия, как noarch.

Идея как раз в том, чтобы не отказываться от noarch.

> Хардлинки сэкономят только место, но при этом создадут массу других 
> проблем тем, кто зеркалит.

Не очевидно, какие проблемы хардлинки могут создать тем, кто зеркалит.
Можно примеры?

> А чем плохи симлинки ? Мы же всё равно симлинкаем в архитектуры пакеты 
> из files. Пусть files остаётся как noarch, а симлинки идут в архитектуру.
> 
> On 10.09.2020 19:16, Vladimir D. Seleznev wrote:
> > По мотивам багрепорта #38919 [1].
> >
> > Рост числа поддерживаемых архитектур, а также утрачивание поддержки
> > 32-хразрядных архитектур апстримами, увеличили сложность отношений между
> > пакетами. Так как, например, скриптам-обёрткам над утилитами совсем не
> > нужно быть архитектурно-зависимыми, зависимость noarch-пакетов на
> > arch-пакеты является валидной, но сейчас всё больше noarch-пакетов
> > фактически становятся архитектурно-зависимыми из-за порождаемых анметов,
> > причины которых описаны в начале.
> >
> > Разрешить эту проблему можно отказавшись от обособленного
> > noarch-репозитория; собранные же noarch-пакеты хардлинкать в
> > arch-репозитории кроме тех, в которых присутствие этих пакетов порождает
> > анметы.
> >
> > [1] https://bugzilla.altlinux.org/show_bug.cgi?id=38919

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] RFC: Merge noarch repo with arch repos

[Anton Farygin]

On 10.09.2020 19:46, Vladimir D. Seleznev wrote:
> On Thu, Sep 10, 2020 at 07:22:08PM +0300, Anton Farygin wrote:
>> Тогда уж проще отказаться от такого понятия, как noarch.
> Идея как раз в том, чтобы не отказываться от noarch.
Если noarch архитектурно-зависимый, то какое же это noarch ?
>
>> Хардлинки сэкономят только место, но при этом создадут массу других
>> проблем тем, кто зеркалит.
> Не очевидно, какие проблемы хардлинки могут создать тем, кто зеркалит.
> Можно примеры?

https://serverfault.com/questions/207370/rsync-with-hard-links-freezes/207693#207693


>
>> А чем плохи симлинки ? Мы же всё равно симлинкаем в архитектуры пакеты
>> из files. Пусть files остаётся как noarch, а симлинки идут в архитектуру.
>>
>> On 10.09.2020 19:16, Vladimir D. Seleznev wrote:
>>> По мотивам багрепорта #38919 [1].
>>>
>>> Рост числа поддерживаемых архитектур, а также утрачивание поддержки
>>> 32-хразрядных архитектур апстримами, увеличили сложность отношений между
>>> пакетами. Так как, например, скриптам-обёрткам над утилитами совсем не
>>> нужно быть архитектурно-зависимыми, зависимость noarch-пакетов на
>>> arch-пакеты является валидной, но сейчас всё больше noarch-пакетов
>>> фактически становятся архитектурно-зависимыми из-за порождаемых анметов,
>>> причины которых описаны в начале.
>>>
>>> Разрешить эту проблему можно отказавшись от обособленного
>>> noarch-репозитория; собранные же noarch-пакеты хардлинкать в
>>> arch-репозитории кроме тех, в которых присутствие этих пакетов порождает
>>> анметы.
>>>
>>> [1] https://bugzilla.altlinux.org/show_bug.cgi?id=38919

Re: [devel] RFC: Merge noarch repo with arch repos

[Igor Vlasenko]

On Thu, Sep 10, 2020 at 08:22:14PM +0300, Anton Farygin wrote:
> > On Thu, Sep 10, 2020 at 07:22:08PM +0300, Anton Farygin wrote:
> > > Тогда уж проще отказаться от такого понятия, как noarch.
> > Идея как раз в том, чтобы не отказываться от noarch.
> Если noarch архитектурно-зависимый, то какое же это noarch ?

есть пакет game, из него собирается game.arch и game-data.noarch
не собрался game.arch на armh. Но если написать excludearch: armh
то появится unmet game-data.noarch requires game.armh на armh.

game-data.noarch noarch архитектурно-зависимый,
но для него сейчас порождается архитектурно-зависимый unmet.


-- 

I V

Re: [devel] RFC: Merge noarch repo with arch repos

[Igor Vlasenko]

On Thu, Sep 10, 2020 at 10:37:06PM +0300, Igor Vlasenko wrote:
> game-data.noarch noarch архитектурно-зависимый,
> но для него сейчас порождается архитектурно-зависимый unmet.

опечатался.
game-data.noarch noarch архитектурно-независимый.

-- 

I V

Re: [devel] RFC: Merge noarch repo with arch repos

[Michael Shigorin]

On Thu, Sep 10, 2020 at 10:37:06PM +0300, Igor Vlasenko wrote:
> > > > Тогда уж проще отказаться от такого понятия, как noarch.
> > > Идея как раз в том, чтобы не отказываться от noarch.
> > Если noarch архитектурно-зависимый, то какое же это noarch ?
> есть пакет game, из него собирается game.arch и game-data.noarch
> не собрался game.arch на armh. Но если написать excludearch: armh
> то появится unmet game-data.noarch requires game.armh на armh.

Пример, надеюсь, синтетический, потому как зависимости обычно
в обратном направлении идут -- у программ на данные.

> game-data.noarch noarch архитектурно-зависимый,
> но для него сейчас порождается архитектурно-зависимый unmet.

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

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] RFC: Merge noarch repo with arch repos

[Igor Vlasenko]

On Thu, Sep 10, 2020 at 11:05:03PM +0300, Michael Shigorin wrote:
> On Thu, Sep 10, 2020 at 10:37:06PM +0300, Igor Vlasenko wrote:
> Пример, надеюсь, синтетический, потому как зависимости обычно
> в обратном направлении идут -- у программ на данные.
> 
> > game-data.noarch noarch архитектурно-зависимый,
> > но для него сейчас порождается архитектурно-зависимый unmet.
> 
> Я могу представить такую ситуацию, но пока не понял,
> это тоже будет заведомый баг или необязательно...

Гм. поcмотрел, wesnoth-data таки не тянет wesnoth.
Но, получается, если мой племянник 10 лет захочет
удалить wesnoth, то wesnoth-data так и останется
в системе, если он не догадается ее явно отметить.
а пакет никому больше не нужен...

-- 

I V

Re: [devel] RFC: Merge noarch repo with arch repos

[Paul Wolneykien]

В Thu, 10 Sep 2020 23:45:39 +0300
Igor Vlasenko <vlasenko@imath.kiev.ua> пишет:

> On Thu, Sep 10, 2020 at 11:05:03PM +0300, Michael Shigorin wrote:
> > On Thu, Sep 10, 2020 at 10:37:06PM +0300, Igor Vlasenko wrote:
> > Пример, надеюсь, синтетический, потому как зависимости обычно
> > в обратном направлении идут -- у программ на данные.
> >   
> > > game-data.noarch noarch архитектурно-зависимый,
> > > но для него сейчас порождается архитектурно-зависимый unmet.  
> > 
> > Я могу представить такую ситуацию, но пока не понял,
> > это тоже будет заведомый баг или необязательно...  
> 
> Гм. поcмотрел, wesnoth-data таки не тянет wesnoth.
> Но, получается, если мой племянник 10 лет захочет
> удалить wesnoth, то wesnoth-data так и останется
> в системе, если он не догадается ее явно отметить.
> а пакет никому больше не нужен...

  Так и ещё сто библиотек останется, как обычно. Без autoremove эту
задачу не решить.

Re: [devel] RFC: Merge noarch repo with arch repos

[Igor Vlasenko]

On Fri, Sep 11, 2020 at 12:23:05AM +0300, Paul Wolneykien wrote:
>   Так и ещё сто библиотек останется, как обычно. Без autoremove эту
> задачу не решить.

Да, согласен. А что у нас есть по autoremove ?

-- 

I V

Re: [devel] RFC: Merge noarch repo with arch repos

[Vladimir D. Seleznev]

On Fri, Sep 11, 2020 at 12:47:58AM +0300, Igor Vlasenko wrote:
> On Fri, Sep 11, 2020 at 12:23:05AM +0300, Paul Wolneykien wrote:
> >   Так и ещё сто библиотек останется, как обычно. Без autoremove эту
> > задачу не решить.
> 
> Да, согласен. А что у нас есть по autoremove ?

apt-get autoremove

Реализовал darktemplar@ полтора года назад.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] RFC: Merge noarch repo with arch repos

[Vitaly Lipatov]

Vladimir D. Seleznev писал 11.9.20 0:54:
> On Fri, Sep 11, 2020 at 12:47:58AM +0300, Igor Vlasenko wrote:
>> On Fri, Sep 11, 2020 at 12:23:05AM +0300, Paul Wolneykien wrote:
>> >   Так и ещё сто библиотек останется, как обычно. Без autoremove эту
>> > задачу не решить.
>> 
>> Да, согласен. А что у нас есть по autoremove ?
> 
> apt-get autoremove
> 
> Реализовал darktemplar@ полтора года назад.

$ eepm autoremove

Реализован 4 года назад.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] RFC: Merge noarch repo with arch repos (autoremove)

[Anton Farygin]

On 12.09.2020 14:33, Vitaly Lipatov wrote:
> Vladimir D. Seleznev писал 11.9.20 0:54:
>> On Fri, Sep 11, 2020 at 12:47:58AM +0300, Igor Vlasenko wrote:
>>> On Fri, Sep 11, 2020 at 12:23:05AM +0300, Paul Wolneykien wrote:
>>> >   Так и ещё сто библиотек останется, как обычно. Без autoremove эту
>>> > задачу не решить.
>>>
>>> Да, согласен. А что у нас есть по autoremove ?
>>
>> apt-get autoremove
>>
>> Реализовал darktemplar@ полтора года назад.
>
> $ eepm autoremove
>
> Реализован 4 года назад.
>
Так у него совершенно другой принцип действия, они скорее друг друга 
дополняют.

Re: [devel] RFC: Merge noarch repo with arch repos

[Anton Farygin]

On 10.09.2020 23:45, Igor Vlasenko wrote:
> On Thu, Sep 10, 2020 at 11:05:03PM +0300, Michael Shigorin wrote:
>> On Thu, Sep 10, 2020 at 10:37:06PM +0300, Igor Vlasenko wrote:
>> Пример, надеюсь, синтетический, потому как зависимости обычно
>> в обратном направлении идут -- у программ на данные.
>>
>>> game-data.noarch noarch архитектурно-зависимый,
>>> но для него сейчас порождается архитектурно-зависимый unmet.
>> Я могу представить такую ситуацию, но пока не понял,
>> это тоже будет заведомый баг или необязательно...
> Гм. поcмотрел, wesnoth-data таки не тянет wesnoth.
> Но, получается, если мой племянник 10 лет захочет
> удалить wesnoth, то wesnoth-data так и останется
> в системе, если он не догадается ее явно отметить.
> а пакет никому больше не нужен...
>
apt-get autoremove работает во всех наших дистрибутивах (начиная с p9).

но вывод autoremove может зависеть от профиля сборки дистрибутива.

Re: [devel] RFC: Merge noarch repo with arch repos

[Sergey V Turchin]

On Friday, 11 September 2020 10:26:11 MSK Anton Farygin wrote:

[...]
> apt-get autoremove работает во всех наших дистрибутивах (начиная с p9).
> но вывод autoremove может зависеть от профиля сборки дистрибутива.
Это ж вроде пофикшено. В конце установки должно делаться apt-mark на всё, что 
указано в списках при установке.

-- 
Regards, Sergey.

Re: [devel] RFC: Merge noarch repo with arch repos

[Sergey V Turchin]

On Friday, 11 September 2020 11:12:05 MSK Sergey V wrote:
> On Friday, 11 September 2020 10:26:11 MSK Anton Farygin wrote:
> 
> [...]
> 
> > apt-get autoremove работает во всех наших дистрибутивах (начиная с p9).
> > но вывод autoremove может зависеть от профиля сборки дистрибутива.
> 
> Это ж вроде пофикшено. В конце установки должно делаться apt-mark на всё,
> что указано в списках при установке.
Даже не так. apt-get autoremove сейчас делается установщиком в конце 
установки.

-- 
Regards, Sergey.

Re: [devel] RFC: Merge noarch repo with arch repos

[Anton Farygin]

On 11.09.2020 11:14, Sergey V Turchin wrote:
> On Friday, 11 September 2020 11:12:05 MSK Sergey V wrote:
>> On Friday, 11 September 2020 10:26:11 MSK Anton Farygin wrote:
>>
>> [...]
>>
>>> apt-get autoremove работает во всех наших дистрибутивах (начиная с p9).
>>> но вывод autoremove может зависеть от профиля сборки дистрибутива.
>> Это ж вроде пофикшено. В конце установки должно делаться apt-mark на всё,
>> что указано в списках при установке.
> Даже не так. apt-get autoremove сейчас делается установщиком в конце
> установки.
>
Да, всё верно. Но если, например, удалить какой-нибуть kde-maxi (для 
примера), который тащил по зависимостям разные пакеты kde, то эти разные 
пакеты kde пометятся для автоудаления.

Re: [devel] RFC: Merge noarch repo with arch repos

[Aleksei Nikiforov]

10.09.2020 23:45, Igor Vlasenko пишет:
> On Thu, Sep 10, 2020 at 11:05:03PM +0300, Michael Shigorin wrote:
>> On Thu, Sep 10, 2020 at 10:37:06PM +0300, Igor Vlasenko wrote:
>> Пример, надеюсь, синтетический, потому как зависимости обычно
>> в обратном направлении идут -- у программ на данные.
>>
>>> game-data.noarch noarch архитектурно-зависимый,
>>> но для него сейчас порождается архитектурно-зависимый unmet.
>>
>> Я могу представить такую ситуацию, но пока не понял,
>> это тоже будет заведомый баг или необязательно...
> 
> Гм. поcмотрел, wesnoth-data таки не тянет wesnoth.
> Но, получается, если мой племянник 10 лет захочет
> удалить wesnoth, то wesnoth-data так и останется
> в системе, если он не догадается ее явно отметить.
> а пакет никому больше не нужен...
> 

С этим должен помочь apt-get autoremove. Пару лет как его реализовал. 
Конечно, реализован он с учётом обратной совместимости, поэтому если 
wesnoth-data был установлен до установки apt-get с реализацией apt-get 
autoremove или не был явно помечен пользователем как "auto" после этого, 
то apt-get autoremove его удалять не должен.

Команда "apt-mark showstate wesnoth-data" должна точно сказать будет ли 
в таком сценарии apt-get autoremove удалять wesnoth-data (если вернёт 
"wesnoth-data auto") или нет (если вернёт "wesnoth-data manual").

Re: [devel] RFC: Merge noarch repo with arch repos

[Igor Vlasenko]

On Fri, Sep 11, 2020 at 10:27:48AM +0300, Aleksei Nikiforov wrote:
> С этим должен помочь apt-get autoremove. Пару лет как его реализовал.
> Конечно, реализован он с учётом обратной совместимости, поэтому если
> wesnoth-data был установлен до установки apt-get с реализацией apt-get
> autoremove или не был явно помечен пользователем как "auto" после этого, то
> apt-get autoremove его удалять не должен.

Круто. спасибо, отличная работа.
Жалко, ее на wiki нет -- такое обязательно нужно документировать.

-- 

I V

Re: [devel] RFC: Merge noarch repo with arch repos

[Alexey V. Vissarionov]

On 2020-09-10 23:05:03 +0300, Michael Shigorin wrote:

 >>>>> Тогда уж проще отказаться от такого понятия, как noarch.
 >>>> Идея как раз в том, чтобы не отказываться от noarch.
 >>> Если noarch архитектурно-зависимый, то какое же это noarch ?
 >> есть пакет game, из него собирается game.arch и game-data.noarch
 >> не собрался game.arch на armh. Но если написать excludearch: armh
 >> то появится unmet game-data.noarch requires game.armh на armh.
 > Пример, надеюсь, синтетический, потому как зависимости обычно
 > в обратном направлении идут -- у программ на данные.

Более реальный пример - зависимость скриптового hasher от бинарного
hasher-priv

 >> game-data.noarch noarch архитектурно-зависимый,
 >> но для него сейчас порождается архитектурно-зависимый unmet.
 > Я могу представить такую ситуацию, но пока не понял, это тоже
 > будет заведомый баг или необязательно...

Баг.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] RFC: Merge noarch repo with arch repos

[Igor Vlasenko]

On Thu, Sep 10, 2020 at 07:46:20PM +0300, Vladimir D. Seleznev wrote:
> > > Разрешить эту проблему можно отказавшись от обособленного
> > > noarch-репозитория; собранные же noarch-пакеты хардлинкать в
> > > arch-репозитории кроме тех, в которых присутствие этих пакетов порождает
> > > анметы.

Хорошая идея.
Единственно, у нас в RPMS.classic симлинки,
разумно не хардлинки, а симлинки из arch/RPMS.classic в files/noarch.

-- 

I V

Re: [devel] RFC: Merge noarch repo with arch repos

[Anton Farygin]

On 10.09.2020 22:32, Igor Vlasenko wrote:
> On Thu, Sep 10, 2020 at 07:46:20PM +0300, Vladimir D. Seleznev wrote:
>>>> Разрешить эту проблему можно отказавшись от обособленного
>>>> noarch-репозитория; собранные же noarch-пакеты хардлинкать в
>>>> arch-репозитории кроме тех, в которых присутствие этих пакетов порождает
>>>> анметы.
> Хорошая идея.
> Единственно, у нас в RPMS.classic симлинки,
> разумно не хардлинки, а симлинки из arch/RPMS.classic в files/noarch.
>
Да, всё верно!

Re: [devel] RFC: Merge noarch repo with arch repos

[Dmitry V. Levin]

On Thu, Sep 10, 2020 at 07:16:27PM +0300, Vladimir D. Seleznev wrote:
> По мотивам багрепорта #38919 [1].
> 
> Рост числа поддерживаемых архитектур, а также утрачивание поддержки
> 32-хразрядных архитектур апстримами, увеличили сложность отношений между
> пакетами. Так как, например, скриптам-обёрткам над утилитами совсем не
> нужно быть архитектурно-зависимыми, зависимость noarch-пакетов на
> arch-пакеты является валидной, но сейчас всё больше noarch-пакетов
> фактически становятся архитектурно-зависимыми из-за порождаемых анметов,
> причины которых описаны в начале.
> 
> Разрешить эту проблему можно отказавшись от обособленного
> noarch-репозитория; собранные же noarch-пакеты хардлинкать в
> arch-репозитории кроме тех, в которых присутствие этих пакетов порождает
> анметы.
> 
> [1] https://bugzilla.altlinux.org/show_bug.cgi?id=38919

https://bugzilla.altlinux.org/show_bug.cgi?id=38919#c4
"(In reply to Ivan A. Melnikov from comment #3)
> очень интересен список потенциально пострадавших
> пакетов. Простой grep по спекам показывает, что таких может быть немало --
> хотя как совсем правильно грепать неясно.
>
> Кстати, среди пострадавших точно будут qboot и seabios. Кто готов вернуть их
> сборку кроссом? Мне бы для mipsel пригодилось =)

+100500

Это PreReq к началу обсуждения."

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

Предложения, не подкреплённые протестированными патчами,
имеют больше шансов остаться благими пожеланиями.


-- 
ldv

Re: [devel] Изменения сборочницы

[Aleksei Nikiforov]

11.09.2020 09:06, Dmitry V. Levin пишет:
> On Thu, Sep 10, 2020 at 07:16:27PM +0300, Vladimir D. Seleznev wrote:
>> По мотивам багрепорта #38919 [1].
>>
>> Рост числа поддерживаемых архитектур, а также утрачивание поддержки
>> 32-хразрядных архитектур апстримами, увеличили сложность отношений между
>> пакетами. Так как, например, скриптам-обёрткам над утилитами совсем не
>> нужно быть архитектурно-зависимыми, зависимость noarch-пакетов на
>> arch-пакеты является валидной, но сейчас всё больше noarch-пакетов
>> фактически становятся архитектурно-зависимыми из-за порождаемых анметов,
>> причины которых описаны в начале.
>>
>> Разрешить эту проблему можно отказавшись от обособленного
>> noarch-репозитория; собранные же noarch-пакеты хардлинкать в
>> arch-репозитории кроме тех, в которых присутствие этих пакетов порождает
>> анметы.
>>
>> [1] https://bugzilla.altlinux.org/show_bug.cgi?id=38919
> 
> https://bugzilla.altlinux.org/show_bug.cgi?id=38919#c4
> "(In reply to Ivan A. Melnikov from comment #3)
>> очень интересен список потенциально пострадавших
>> пакетов. Простой grep по спекам показывает, что таких может быть немало --
>> хотя как совсем правильно грепать неясно.
>>
>> Кстати, среди пострадавших точно будут qboot и seabios. Кто готов вернуть их
>> сборку кроссом? Мне бы для mipsel пригодилось =)
> 
> +100500
> 
> Это PreReq к началу обсуждения."
> 
> Ещё у меня есть пожелание ко всем, кто предлагает изменения структуры
> репозитория, оценивать сложность предлагаемых изменений, а также иметь
> в виду, что любые изменения должны обеспечивать полную обратную
> совместимость.
> 
> Предложения, не подкреплённые протестированными патчами,
> имеют больше шансов остаться благими пожеланиями.
> 
> 

Если для предложений нужны задания и оценки изменений, вносимых ими, 
прошу посмотреть на баг http://bugzilla.altlinux.org/37035 и задание 
#257429 с одним из вариантов решения проблемы.

Пакеты, для которых изменится поведение: wine, wine-vanilla, 
mozilla-plugin-adobe-flash. Полный список здесь на второй строке:

http://git.altlinux.org/gears/r/rpmrebuild-arepo.git?p=rpmrebuild-arepo.git;a=blob;f=rpmrebuild-arepo.conf;h=81dd76492be893ac339737914f72bf53023d700b;hb=083731da52c5043efa82fed762b40a8a00289d6b#l2

Пакет mozilla-plugin-adobe-flash давно пустой, в нём от этого изменения 
ничего не изменится.

Для пакетов wine и wine-vanilla это позволит, после того как в них 
исправят файловые конфликты с i586-wine и i586-wine-vanilla 
соответственно, наконец получить работоспособный multilib wine в ALT. 
Для полноценной работы 64битных приложений недостаточно 64битного wine. 
Нужен и 64битный wine, и 32битный wine, и они нужны установленные 
одновременно.

Прошу не тормозить с решением этой проблемы.

Re: [devel] wine and arepo in prog mode

[Dmitry V. Levin]

On Fri, Sep 11, 2020 at 10:44:35AM +0300, Aleksei Nikiforov wrote:
[...]
> Если для предложений нужны задания и оценки изменений, вносимых ими, 
> прошу посмотреть на баг http://bugzilla.altlinux.org/37035 и задание 
> #257429 с одним из вариантов решения проблемы.
> 
> Пакеты, для которых изменится поведение: wine, wine-vanilla, 
> mozilla-plugin-adobe-flash. Полный список здесь на второй строке:
> 
> http://git.altlinux.org/gears/r/rpmrebuild-arepo.git?p=rpmrebuild-arepo.git;a=blob;f=rpmrebuild-arepo.conf;h=81dd76492be893ac339737914f72bf53023d700b;hb=083731da52c5043efa82fed762b40a8a00289d6b#l2
> 
> Пакет mozilla-plugin-adobe-flash давно пустой, в нём от этого изменения 
> ничего не изменится.
> 
> Для пакетов wine и wine-vanilla это позволит, после того как в них 
> исправят файловые конфликты с i586-wine и i586-wine-vanilla 
> соответственно, наконец получить работоспособный multilib wine в ALT. 
> Для полноценной работы 64битных приложений недостаточно 64битного wine. 
> Нужен и 64битный wine, и 32битный wine, и они нужны установленные 
> одновременно.

В то время, когда решался https://bugzilla.altlinux.org/22985,
wine и i586-wine конфликтовали по файлам, поэтому добавление тэга
Conflicts было не только оправданным, но и необходимым.

Насколько я понимаю, wine и i586-wine до сих пор продолжают конфликтовать
по файлам (ср. напр. /usr/bin/wineserver), поэтому убирать тэг Conflicts
пока ещё рано.

Поэтому порядок действий должен быть следующим:
сперва исправляются пакеты, потом тэг Conflicts заменяется на Requires.


-- 
ldv

Re: [devel] wine and arepo in prog mode

[Aleksei Nikiforov]

11.09.2020 11:13, Dmitry V. Levin пишет:
> On Fri, Sep 11, 2020 at 10:44:35AM +0300, Aleksei Nikiforov wrote:
> [...]
>> Если для предложений нужны задания и оценки изменений, вносимых ими,
>> прошу посмотреть на баг http://bugzilla.altlinux.org/37035 и задание
>> #257429 с одним из вариантов решения проблемы.
>>
>> Пакеты, для которых изменится поведение: wine, wine-vanilla,
>> mozilla-plugin-adobe-flash. Полный список здесь на второй строке:
>>
>> http://git.altlinux.org/gears/r/rpmrebuild-arepo.git?p=rpmrebuild-arepo.git;a=blob;f=rpmrebuild-arepo.conf;h=81dd76492be893ac339737914f72bf53023d700b;hb=083731da52c5043efa82fed762b40a8a00289d6b#l2
>>
>> Пакет mozilla-plugin-adobe-flash давно пустой, в нём от этого изменения
>> ничего не изменится.
>>
>> Для пакетов wine и wine-vanilla это позволит, после того как в них
>> исправят файловые конфликты с i586-wine и i586-wine-vanilla
>> соответственно, наконец получить работоспособный multilib wine в ALT.
>> Для полноценной работы 64битных приложений недостаточно 64битного wine.
>> Нужен и 64битный wine, и 32битный wine, и они нужны установленные
>> одновременно.
> 
> В то время, когда решался https://bugzilla.altlinux.org/22985,
> wine и i586-wine конфликтовали по файлам, поэтому добавление тэга
> Conflicts было не только оправданным, но и необходимым.
> 
> Насколько я понимаю, wine и i586-wine до сих пор продолжают конфликтовать
> по файлам (ср. напр. /usr/bin/wineserver), поэтому убирать тэг Conflicts
> пока ещё рано.
> 
> Поэтому порядок действий должен быть следующим:
> сперва исправляются пакеты, потом тэг Conflicts заменяется на Requires.
> 
> 

Я думаю, можно попробовать и в таком варианте решение. От конфликтов по 
файлам всё равно надо будет избавляться для multilib wine. Если у lav@ 
не будет возражений, я подготовлю задание с wine и wine-vanilla в test-only.

Re: [devel] wine and arepo in prog mode

[Vitaly Lipatov]

Aleksei Nikiforov писал 11.9.20 11:23:
> 11.09.2020 11:13, Dmitry V. Levin пишет:
...
>> В то время, когда решался https://bugzilla.altlinux.org/22985,
>> wine и i586-wine конфликтовали по файлам, поэтому добавление тэга
>> Conflicts было не только оправданным, но и необходимым.
>> 
>> Насколько я понимаю, wine и i586-wine до сих пор продолжают 
>> конфликтовать
>> по файлам (ср. напр. /usr/bin/wineserver), поэтому убирать тэг 
>> Conflicts
>> пока ещё рано.
>> 
>> Поэтому порядок действий должен быть следующим:
>> сперва исправляются пакеты, потом тэг Conflicts заменяется на 
>> Requires.
+1
Но у меня есть подозрение, что исправление пакетов временно сломает 
i586-*wine*.

> Я думаю, можно попробовать и в таком варианте решение. От конфликтов
> по файлам всё равно надо будет избавляться для multilib wine. Если у
> lav@ не будет возражений, я подготовлю задание с wine и wine-vanilla в
> test-only.
Как будто тут просто задание подготовить. Такое задание уже давно есть, 
с июня висит.
http://git.altlinux.org/tasks/253386/gears/140/git?p=git;a=commitdiff;h=c6841c02cbfe7c71dac900a57df561d7359ff999

План примерно такой:
Добавляются подпакеты
wine-core — с бинарниками
wine-common — с noarch-файлами (в том числе и скриптами запуска)
Сам пакет wine начинает стремиться к мета-пакету, который «ставит полный 
wine», но не настолько всё, как wine-full.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] wine and arepo in prog mode

[Dmitry V. Levin]

On Fri, Sep 11, 2020 at 12:16:35PM +0300, Vitaly Lipatov wrote:
> Aleksei Nikiforov писал 11.9.20 11:23:
> > 11.09.2020 11:13, Dmitry V. Levin пишет:
> ...
> >> В то время, когда решался https://bugzilla.altlinux.org/22985,
> >> wine и i586-wine конфликтовали по файлам, поэтому добавление тэга
> >> Conflicts было не только оправданным, но и необходимым.
> >> 
> >> Насколько я понимаю, wine и i586-wine до сих пор продолжают 
> >> конфликтовать
> >> по файлам (ср. напр. /usr/bin/wineserver), поэтому убирать тэг 
> >> Conflicts
> >> пока ещё рано.
> >> 
> >> Поэтому порядок действий должен быть следующим:
> >> сперва исправляются пакеты, потом тэг Conflicts заменяется на 
> >> Requires.
> +1
> Но у меня есть подозрение, что исправление пакетов временно сломает 
> i586-*wine*.

Можно объединить исправление пакетов с обновлением rpmrebuild-arepo
в одно задание, если нужно.


-- 
ldv

Re: [devel] wine and arepo in prog mode

[Aleksei Nikiforov]

11.09.2020 13:13, Dmitry V. Levin пишет:
> On Fri, Sep 11, 2020 at 12:16:35PM +0300, Vitaly Lipatov wrote:
>> Aleksei Nikiforov писал 11.9.20 11:23:
>>> 11.09.2020 11:13, Dmitry V. Levin пишет:
>> ...
>>>> В то время, когда решался https://bugzilla.altlinux.org/22985,
>>>> wine и i586-wine конфликтовали по файлам, поэтому добавление тэга
>>>> Conflicts было не только оправданным, но и необходимым.
>>>>
>>>> Насколько я понимаю, wine и i586-wine до сих пор продолжают
>>>> конфликтовать
>>>> по файлам (ср. напр. /usr/bin/wineserver), поэтому убирать тэг
>>>> Conflicts
>>>> пока ещё рано.
>>>>
>>>> Поэтому порядок действий должен быть следующим:
>>>> сперва исправляются пакеты, потом тэг Conflicts заменяется на
>>>> Requires.
>> +1
>> Но у меня есть подозрение, что исправление пакетов временно сломает
>> i586-*wine*.
> 
> Можно объединить исправление пакетов с обновлением rpmrebuild-arepo
> в одно задание, если нужно.
> 
> 

Подумал об этом ещё немного, и мне кажется замена Conflicts на Requires 
- это не совсем верно. Для работы i586-wine не нужен wine. Это для 
работы wine на x86_64 обычно нужен i586-wine, а не наоборот. Но от 
Requires от i586-wine на wine, конечно, много вреда быть не должно.

Если можно в одном задании сделать обновление rpmrebuild-arepo, с 
изменением списка пакетов, для которых включен режим prog arepo, то на 
основе задания lav@ #253386 вполне можно сделать соответствующие 
изменения в wine и wine-vanilla, а также добавить в rpmrebuild-arepo 
${winevariant}-core в режим prog для каждого $winevariant, если сразу же 
и сделать вынос части файлов в соответствующие пакеты.

2 lav@: мне кажется в том задании переименование wine в wine32 и 
wine-preloader в wine{32,64}-preloader излишним. А вот чтобы не ломать 
отдельно установленный i586-wine, скрипт для wineserver и переименование 
бинарей в wineserver{32,64} (или wine{32,64}server), скорее всего, то 
что нужно, но это стоит ещё перепроверить.

Поставил wine-staging-core, libwine-staging-gl, i586-wine-staging-core, 
i586-libwine-staging-gl из установленного задания, а также скопировал 
/usr/bin/wine32{,-preloader,server} из пакета для i586, и оно не 
заработало в текущем виде:

$ winecfg
wine: created the configuration directory '/home/test/.wine'
/usr/bin/wine3264: could not open
0024:err:environ:run_wineboot failed to start wineboot c00000e5
/usr/bin/wine3264: could not open
/usr/bin/wine3264: could not open
0024:err:winecfg:WinMain failed to restart 64-bit 
L"C:\\windows\\system32\\winecfg.exe", err 1359
0024:err:winediag:nodrv_CreateWindow Application tried to create a 
window, but no driver could be loaded.
0024:err:winediag:nodrv_CreateWindow The explorer process failed to start.

Из-за переименования wine в wine32 ищется wine3264 вместо wine64.

Повторю, что могу заняться подготовкой работоспособного задания в test-only.

Re: [devel] wine and arepo in prog mode

[Vitaly Lipatov]

Aleksei Nikiforov писал 11.9.20 14:47:
> 11.09.2020 13:13, Dmitry V. Levin пишет:
>> On Fri, Sep 11, 2020 at 12:16:35PM +0300, Vitaly Lipatov wrote:
>>> Aleksei Nikiforov писал 11.9.20 11:23:
>>>> 11.09.2020 11:13, Dmitry V. Levin пишет:
>>> ...
>>>>> В то время, когда решался https://bugzilla.altlinux.org/22985,
>>>>> wine и i586-wine конфликтовали по файлам, поэтому добавление тэга
>>>>> Conflicts было не только оправданным, но и необходимым.
>>>>> 
>>>>> Насколько я понимаю, wine и i586-wine до сих пор продолжают
>>>>> конфликтовать
>>>>> по файлам (ср. напр. /usr/bin/wineserver), поэтому убирать тэг
>>>>> Conflicts
>>>>> пока ещё рано.
>>>>> 
>>>>> Поэтому порядок действий должен быть следующим:
>>>>> сперва исправляются пакеты, потом тэг Conflicts заменяется на
>>>>> Requires.
>>> +1
>>> Но у меня есть подозрение, что исправление пакетов временно сломает
>>> i586-*wine*.
>> 
>> Можно объединить исправление пакетов с обновлением rpmrebuild-arepo
>> в одно задание, если нужно.
>> 
>> 
> 
> Подумал об этом ещё немного, и мне кажется замена Conflicts на
> Requires - это не совсем верно. Для работы i586-wine не нужен wine.
> Это для работы wine на x86_64 обычно нужен i586-wine, а не наоборот.
> Но от Requires от i586-wine на wine, конечно, много вреда быть не
> должно.
Просто обычно в x86_64-пакете есть ещё архитектурно-независимые файлы, 
которые вырезаны из arepo, и чтобы программа из i586- могла до них 
дойти, и добавляется Requires. Особо проблемы тут я не вижу, потому что 
смысла запускать только 32 битное окружение всё меньше. Но необходимость 
Requires можно будет обсудить, когда пакеты будут упакованы так, что 
arepo не придётся из них ничего вырезать.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] wine and arepo in prog mode

[Michael Shigorin]

On Fri, Sep 11, 2020 at 03:01:37PM +0300, Vitaly Lipatov wrote:
> > Подумал об этом ещё немного, и мне кажется замена Conflicts
> > на Requires - это не совсем верно. Для работы i586-wine не
> > нужен wine.  Это для работы wine на x86_64 обычно нужен
> > i586-wine, а не наоборот.
> Просто обычно в x86_64-пакете есть ещё архитектурно-независимые
> файлы, которые вырезаны из arepo, и чтобы программа из i586-
> могла до них дойти, и добавляется Requires.

Как вариант, можно вынести пересекающееся в wine-common.
Но и впрямь не уверен, что есть особый смысл.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] wine and arepo in prog mode

[Vitaly Lipatov]

Michael Shigorin писал 11.9.20 15:36:
> On Fri, Sep 11, 2020 at 03:01:37PM +0300, Vitaly Lipatov wrote:
>> > Подумал об этом ещё немного, и мне кажется замена Conflicts
>> > на Requires - это не совсем верно. Для работы i586-wine не
>> > нужен wine.  Это для работы wine на x86_64 обычно нужен
>> > i586-wine, а не наоборот.
>> Просто обычно в x86_64-пакете есть ещё архитектурно-независимые
>> файлы, которые вырезаны из arepo, и чтобы программа из i586-
>> могла до них дойти, и добавляется Requires.
> 
> Как вариант, можно вынести пересекающееся в wine-common.
> Но и впрямь не уверен, что есть особый смысл.
По этому вопросу у меня мнение, что пакеты
i586-wine в репозитории x86_64-i586
и
wine в репозитории i586
не должны отличаться.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] wine and arepo in prog mode

[Vitaly Lipatov]

Aleksei Nikiforov писал 11.9.20 14:47:
...
> 2 lav@: мне кажется в том задании переименование wine в wine32 и
> wine-preloader в wine{32,64}-preloader излишним. А вот чтобы не ломать

Чтобы сделать выводы, нужно прочитать
https://wiki.winehq.org/Packaging
посмотреть, как упакован wine в Debian и Fedora.

> отдельно установленный i586-wine, скрипт для wineserver и
> переименование бинарей в wineserver{32,64} (или wine{32,64}server),
> скорее всего, то что нужно, но это стоит ещё перепроверить.
> 
> Поставил wine-staging-core, libwine-staging-gl,
> i586-wine-staging-core, i586-libwine-staging-gl из установленного
> задания, а также скопировал /usr/bin/wine32{,-preloader,server} из
> пакета для i586, и оно не заработало в текущем виде:
> 
> $ winecfg
> wine: created the configuration directory '/home/test/.wine'
> /usr/bin/wine3264: could not open
> 0024:err:environ:run_wineboot failed to start wineboot c00000e5
> /usr/bin/wine3264: could not open
> /usr/bin/wine3264: could not open
> 0024:err:winecfg:WinMain failed to restart 64-bit
> L"C:\\windows\\system32\\winecfg.exe", err 1359
> 0024:err:winediag:nodrv_CreateWindow Application tried to create a
> window, but no driver could be loaded.
> 0024:err:winediag:nodrv_CreateWindow The explorer process failed to 
> start.
> 
> Из-за переименования wine в wine32 ищется wine3264 вместо wine64.
Ну это небольшая бага, хорошо бы найти её. Лучше все изыскания вести в 
баге, например, в
https://bugzilla.altlinux.org/show_bug.cgi?id=37035

> Повторю, что могу заняться подготовкой работоспособного задания в 
> test-only.
Конечно, я буду признателен за подсказку, что не так с заданием #253386
Когда мы определимся со структурой, я перенесу ещё на новую сборку.
На всякий случай напишу ещё здесь, что мне кажется хорошей идеей сделать 
так, чтобы 32-битные пакеты и пакеты после arepo не отличались.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] wine and arepo in prog mode

[Vitaly Lipatov]

Dmitry V. Levin писал 11.9.20 13:13:
> On Fri, Sep 11, 2020 at 12:16:35PM +0300, Vitaly Lipatov wrote:
>> Aleksei Nikiforov писал 11.9.20 11:23:
>> > 11.09.2020 11:13, Dmitry V. Levin пишет:
>> ...
>> >> В то время, когда решался https://bugzilla.altlinux.org/22985,
>> >> wine и i586-wine конфликтовали по файлам, поэтому добавление тэга
>> >> Conflicts было не только оправданным, но и необходимым.
>> >>
>> >> Насколько я понимаю, wine и i586-wine до сих пор продолжают
>> >> конфликтовать
>> >> по файлам (ср. напр. /usr/bin/wineserver), поэтому убирать тэг
>> >> Conflicts
>> >> пока ещё рано.
>> >>
>> >> Поэтому порядок действий должен быть следующим:
>> >> сперва исправляются пакеты, потом тэг Conflicts заменяется на
>> >> Requires.
>> +1
>> Но у меня есть подозрение, что исправление пакетов временно сломает
>> i586-*wine*.
> 
> Можно объединить исправление пакетов с обновлением rpmrebuild-arepo
> в одно задание, если нужно.
Объединил в одно задание:
http://git.altlinux.org/tasks/285392/logs/events.7.1.log

Пакеты wine* и i586-wine* не конфликтуют по файлам.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] wine and arepo in prog mode

[Anton V. Boyarshinov]

В Fri, 11 Sep 2020 11:13:54 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> Насколько я понимаю, wine и i586-wine до сих пор продолжают конфликтовать
> по файлам (ср. напр. /usr/bin/wineserver), поэтому убирать тэг Conflicts
> пока ещё рано.

Я ничего об этом не знаю, но, меня терзает сомнение: если на 64-битных
машинах будет 2 разных wineserver -- будет ли корректно работать
wine-64? Ему же не просто так нужен wine-32...

Re: [devel] wine and arepo in prog mode

[Vitaly Lipatov]

Anton V. Boyarshinov писал 11.9.20 11:26:
> В Fri, 11 Sep 2020 11:13:54 +0300
> "Dmitry V. Levin" <ldv@altlinux.org> пишет:
> 
>> Насколько я понимаю, wine и i586-wine до сих пор продолжают 
>> конфликтовать
>> по файлам (ср. напр. /usr/bin/wineserver), поэтому убирать тэг 
>> Conflicts
>> пока ещё рано.
> 
> Я ничего об этом не знаю, но, меня терзает сомнение: если на 64-битных
> машинах будет 2 разных wineserver -- будет ли корректно работать
> wine-64? Ему же не просто так нужен wine-32...
На 64-битных машинах код обеих разрядностей будет обращаться к wine64. 
Тут как с ядром Linux.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] wine and arepo in prog mode

[Aleksei Nikiforov]

11.09.2020 11:26, Anton V. Boyarshinov пишет:
> В Fri, 11 Sep 2020 11:13:54 +0300
> "Dmitry V. Levin" <ldv@altlinux.org> пишет:
> 
>> Насколько я понимаю, wine и i586-wine до сих пор продолжают конфликтовать
>> по файлам (ср. напр. /usr/bin/wineserver), поэтому убирать тэг Conflicts
>> пока ещё рано.
> 
> Я ничего об этом не знаю, но, меня терзает сомнение: если на 64-битных
> машинах будет 2 разных wineserver -- будет ли корректно работать
> wine-64? Ему же не просто так нужен wine-32...

Я этот момент перепроверю в плане того, как именно это делается. Одно 
могу сказать точно: wine 32битный и 64битный уживаются на одной системе 
точно.

Если не ошибаюсь, то одного wineserver, общего для двух архитектур, 
должно хватать.

Вот результат перепроверки:

# apt-get install i586-wine i586-libwine-gl
# apt-get install wine libwine-gl
тут удаляется i586-wine, но все его зависимости остаются в системе.

# apt-get install winetricks

$ winetricks -q vcrun2015
------------------------------------------------------
WINE is wine, which is neither on the path nor an executable file
------------------------------------------------------

$ WINE=wine64 winetricks -q vcrun2015
Executing mkdir -p /home/test
...
Executing cd /home/test/.cache/winetricks/vcrun2015
Executing wine64 vc_redist.x86.exe
002c:fixme:winediag:__wine_start_process Wine Staging 5.16 is a testing 
version containing experimental patches.
002c:fixme:winediag:__wine_start_process Please mention your exact 
version when filing bug reports on winehq.org.
0024:err:module:process_init L"Y:\\vcrun2015\\vc_redist.x86.exe" not 
supported on this system
------------------------------------------------------
Важно: команда wine64 vc_redist.x86.exe вернула статус 123. Прерывание.
------------------------------------------------------

Сейчас wine 64битный не в состоянии запустить 32битное приложение 
vc_redist.x86.exe.

Теперь для теста поставим обе версии wine, поставив wine поверх 
i586-wine (и для теста перетерев все общие файлы).

# apt-get install i586-wine
тут удаляется wine, но все его зависимости остаются в системе.

$ file /usr/bin/wineserver
/usr/bin/wineserver: ELF 32-bit LSB executable, Intel 80386, version 1 
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.2.0, stripped

# rpm -i --nodeps --replacefiles 
/mnt/repo/Sisyphus/x86_64/RPMS.classic/wine-5.16.1-alt3.x86_64.rpm
Устанавливаю wine перетирая все конфликтующие файлы из i586-wine.

$ file /usr/bin/wineserver
/usr/bin/wineserver: ELF 64-bit LSB executable, x86-64, version 1 
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.2.0, stripped

Удаляю старый префикс wine. Можно было бы и другой взять, но для тестов 
это не нужно.

$ rm -rf ~/.wine

$ winetricks -q vcrun2015
Executing mkdir -p /home/test
...
успешно завершается
$ winecfg

На вкладке "Библиотеки" можно наблюдать кучу установленных библиотек из 
vcrun2015, которых там не было до выполнения "winetricks -q vcrun2015". 
Можно удалить префикс ~/.wine (или указать другой через переменную 
окружения WINEPREFIX) и убедиться.

Это говорит о том, что 32-битное приложение (инсталлятор vcrun2015 в 
данном случае) на установленном таким образом wine работает нормально.

Теперь нужно 64битное приложение ещё. Качаю с сайта blender 
https://www.blender.org/download/ portable версию для windows 64bit.

$ unzip blender-2.90.0-windows64.zip
$ cd blender-2.90.0-windows64
$ file blender.exe
blender.exe: PE32+ executable for MS Windows (console) Mono/.Net assembly

У blender файл - похоже 64битный, а вот у установщиков vcrun2015 - 32битные:

$ file ~/.cache/winetricks/vcrun2015/vc_redist.x86.exe
/home/test/.cache/winetricks/vcrun2015/vc_redist.x86.exe: PE32 
executable for MS Windows (GUI) Intel 80386 32-bit
$ file ~/.cache/winetricks/vcrun2015/vc_redist.x64.exe
/home/test/.cache/winetricks/vcrun2015/vc_redist.x64.exe: PE32 
executable for MS Windows (GUI) Intel 80386 32-bit

$ wine blender.exe

Запустилось, работает. Сохранил информацию о системе. Из файла:

=====================================
= Blender 2.90.0 System Information =
=====================================


Blender:
=====================================

version: 2.90.0, branch: master, commit date: 2020-08-31 11:26, hash: 
0330d1af29c0, type: Release
build date: 2020-08-31, 10:00:13
platform: Windows
binary path: 'Z:\\home\\test\\blender-2.90.0-windows64\\blender.exe'
build cflags: /W3 /w34062 /w34115 /w34189 /wd4018 /wd4146 /wd4065 
/wd4127 /wd4181 /wd4200 /wd4244 /wd4267 /wd4305 /wd4800 /wd4828 /wd4996 
/wd4661 /we4013 /we4133 /we4431 /w35038 /DWIN32 /D_WINDOWS /W3 /nologo 
/J /Gd /MP /bigobj -openmp
build cxxflags: /W3 /w34062 /w34115 /w34189 /wd4018 /wd4146 /wd4065 
/wd4127 /wd4181 /wd4200 /wd4244 /wd4267 /wd4305 /wd4800 /wd4828 /wd4996 
/wd4661 /we4013 /we4133 /we4431 /w35038 /DWIN32 /D_WINDOWS /W3 /GR /EHsc 
/nologo /J /Gd /MP /EHsc /bigobj /permissive- /Zc:twoPhase- -openmp 
/std:c++17
build linkflags: /MACHINE:X64  /SUBSYSTEM:CONSOLE /STACK:2097152 
/ignore:4049 /ignore:4217 /ignore:4221
build system: CMake

Python:
=====================================

version: 3.7.7 (default, Jun 13 2020, 11:11:23) [MSC v.1916 64 bit (AMD64)]



Стоит обратить внимание на "[MSC v.1916 64 bit (AMD64)]" из версии 
питона и "/MACHINE:X64" из build linkflags у blender.

Для других 64битных и 32битных приложений всё тоже должно работать в 
соответствии с https://appdb.winehq.org.

Также можно взять blender не portable, а установщик, и запустить его:

$ wine msiexec /i blender-2.90.0-windows64.msi

Re: [devel] wine and arepo in prog mode

[Konstantin Lepikhov]

Hi Dmitry!

On 09/11/2020, at 11:13:54 AM you wrote:

<skip>
> Насколько я понимаю, wine и i586-wine до сих пор продолжают конфликтовать
> по файлам (ср. напр. /usr/bin/wineserver), поэтому убирать тэг Conflicts
> пока ещё рано.
> 
> Поэтому порядок действий должен быть следующим:
> сперва исправляются пакеты, потом тэг Conflicts заменяется на Requires.

https://lists.unsafe.ru/pipermail/kernels/2019-March/000510.html

$ rpm -qa |fgrep wine-staging
wine-staging-programs-5.16-alt1.noarch
i586-libwine-staging-vulkan-5.16-alt1.i586
libwine-staging-gl-5.16-alt1.x86_64
i586-libwine-staging-5.16-alt1.i586
i586-wine-staging-5.16-alt1.i586
i586-libwine-staging-gl-5.16-alt1.i586
libwine-staging-vulkan-5.16-alt1.x86_64
libwine-staging-5.16-alt1.x86_64
libwine-staging-opencl-5.16-alt1.x86_64
wine-staging-5.16-alt1.x86_64

В моей сборке biarch работает уже второй год )

-- 
WBR et al.

Re: [devel] RFC: Merge noarch repo with arch repos

[Vladimir D. Seleznev]

On Fri, Sep 11, 2020 at 09:06:14AM +0300, Dmitry V. Levin wrote:
> On Thu, Sep 10, 2020 at 07:16:27PM +0300, Vladimir D. Seleznev wrote:
> > По мотивам багрепорта #38919 [1].
> > 
> > Рост числа поддерживаемых архитектур, а также утрачивание поддержки
> > 32-хразрядных архитектур апстримами, увеличили сложность отношений между
> > пакетами. Так как, например, скриптам-обёрткам над утилитами совсем не
> > нужно быть архитектурно-зависимыми, зависимость noarch-пакетов на
> > arch-пакеты является валидной, но сейчас всё больше noarch-пакетов
> > фактически становятся архитектурно-зависимыми из-за порождаемых анметов,
> > причины которых описаны в начале.
> > 
> > Разрешить эту проблему можно отказавшись от обособленного
> > noarch-репозитория; собранные же noarch-пакеты хардлинкать в
> > arch-репозитории кроме тех, в которых присутствие этих пакетов порождает
> > анметы.
> > 
> > [1] https://bugzilla.altlinux.org/show_bug.cgi?id=38919
> 
> https://bugzilla.altlinux.org/show_bug.cgi?id=38919#c4
> "(In reply to Ivan A. Melnikov from comment #3)
> > очень интересен список потенциально пострадавших
> > пакетов. Простой grep по спекам показывает, что таких может быть немало --
> > хотя как совсем правильно грепать неясно.
> >
> > Кстати, среди пострадавших точно будут qboot и seabios. Кто готов вернуть их
> > сборку кроссом? Мне бы для mipsel пригодилось =)
> 
> +100500
> 
> Это PreReq к началу обсуждения."
> 
> Ещё у меня есть пожелание ко всем, кто предлагает изменения структуры
> репозитория, оценивать сложность предлагаемых изменений, а также иметь
> в виду, что любые изменения должны обеспечивать полную обратную
> совместимость.

На счёт обратной совместимости: для обратной совместимости отдельный
репозиторий noarch останется, но в идеале будет пустым. При каждой новой
сборке предполагается, что noarch-пакеты будут попадать в
arch-репозитории, тем самым с течением времени количество пакетов будет
уменьшаться.

P.S. Я выше написал про использование жёстких ссылок, но забыл, что в
структуре репозиториев используются символические ссылки. Да, надо
использовать символические ссылки.

> Предложения, не подкреплённые протестированными патчами,
> имеют больше шансов остаться благими пожеланиями.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] RFC: Merge noarch repo with arch repos

[Leonid Krivoshein]

10.09.2020 19:16, Vladimir D. Seleznev пишет:
> По мотивам багрепорта #38919 [1].
>
> Рост числа поддерживаемых архитектур, а также утрачивание поддержки
> 32-хразрядных архитектур апстримами, увеличили сложность отношений между
> пакетами. Так как, например, скриптам-обёрткам над утилитами совсем не
> нужно быть архитектурно-зависимыми, зависимость noarch-пакетов на
> arch-пакеты является валидной, но сейчас всё больше noarch-пакетов
> фактически становятся архитектурно-зависимыми из-за порождаемых анметов,
> причины которых описаны в начале.
>
> Разрешить эту проблему можно отказавшись от обособленного
> noarch-репозитория; собранные же noarch-пакеты хардлинкать в
> arch-репозитории кроме тех, в которых присутствие этих пакетов порождает
> анметы.
>
> [1] https://bugzilla.altlinux.org/show_bug.cgi?id=38919

Наверняка мы не первые, кто столкнулся с последствиями размножения 
архитектур и исторически сложившейся упаковки в noarch всего, что не 
исполняемый код, за единичными исключениями. С точки зрения политик 
проверки того, что пакуется в arch и noarch, а также с учётом исходного 
назначения репозитория, логично завести ещё один репозиторий для 
"arch-специфичного noarch" -- "archdata".


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] RFC: Merge noarch repo with arch repos

[Igor Vlasenko]

On Sun, Sep 13, 2020 at 01:33:10AM +0300, Leonid Krivoshein wrote:
> Наверняка мы не первые, кто столкнулся с последствиями размножения
> архитектур и исторически сложившейся упаковки в noarch всего, что не
> исполняемый код, за единичными исключениями. С точки зрения политик проверки
> того, что пакуется в arch и noarch, а также с учётом исходного назначения
> репозитория, логично завести ещё один репозиторий для "arch-специфичного
> noarch" -- "archdata".

Гм, излишне. Зачем ложить в "archdata", если уже есть arch?
Если зачем-то нужен "noarch собираемый везде",
то для него можно оставить старый noarch, 
а симлинки для "noarch собираемый на части arch" держать в arch.

-- 

I V

Re: [devel] RFC: Merge noarch repo with arch repos

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

On Sun, 13 Sep 2020 16:41:36 +0300 Igor Vlasenko wrote:
> On Sun, Sep 13, 2020 at 01:33:10AM +0300, Leonid Krivoshein wrote:
> > Наверняка мы не первые, кто столкнулся с последствиями размножения
> > архитектур и исторически сложившейся упаковки в noarch всего, что не
> > исполняемый код, за единичными исключениями. С точки зрения политик проверки
> > того, что пакуется в arch и noarch, а также с учётом исходного назначения
> > репозитория, логично завести ещё один репозиторий для "arch-специфичного
> > noarch" -- "archdata".
> 
> Гм, излишне. Зачем ложить в "archdata", если уже есть arch?
> Если зачем-то нужен "noarch собираемый везде",
> то для него можно оставить старый noarch, 
> а симлинки для "noarch собираемый на части arch" держать в arch.

Я так понимаю, что у нас есть потребность в «пакет, общий для
архитектур A и B, но не C», а текущая архитектура репозиториев —
та самая, что разрабатывалась давным-давно для схемы «есть только
две архитектуры: i686 и x86_64». От этой схемы мы давно ушли,
а архитектурные проблемы остались.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] partial noarch

[Dmitry V. Levin]

On Sun, Sep 13, 2020 at 05:41:03PM +0300, Andrey Savchenko wrote:
[...]
> Я так понимаю, что у нас есть потребность в «пакет, общий для
> архитектур A и B, но не C»

Ну вот совершенно не очевидно, что у нас есть такая потребность.


-- 
ldv

Re: [devel] partial noarch

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Sun, 13 Sep 2020 17:55:15 +0300 Dmitry V. Levin wrote:
> On Sun, Sep 13, 2020 at 05:41:03PM +0300, Andrey Savchenko wrote:
> [...]
> > Я так понимаю, что у нас есть потребность в «пакет, общий для
> > архитектур A и B, но не C»
> 
> Ну вот совершенно не очевидно, что у нас есть такая потребность.

Она ровно та же, что и в noarch: экономия места и упрощение
синхронизации зеркал без ада с жёсткими ссылками.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] partial noarch

[Leonid Krivoshein]

13.09.2020 17:55, Dmitry V. Levin пишет:
> On Sun, Sep 13, 2020 at 05:41:03PM +0300, Andrey Savchenko wrote:
> [...]
>> Я так понимаю, что у нас есть потребность в «пакет, общий для
>> архитектур A и B, но не C»
> Ну вот совершенно не очевидно, что у нас есть такая потребность.

Если мы полагаемся только на оптимизацию (реализацию), то есть ли у нас 
вообще потребность в noarch?


-- 
Best regards,
Leonid Krivoshein.