ALT Linux Bugzilla – #39889

Да, vendor для rust нехорошо класть в общий каталог: его надо паковать в отдельный тарбол.
Если нужно, могу сделать на свой лад.

(In reply to Vitaly Lipatov from comment #1)
> Да, vendor для rust нехорошо класть в общий каталог: его надо паковать в
> отдельный тарбол.
> Если нужно, могу сделать на свой лад.

Для чистых rust (и, например, go) пакетов я не соглашусь, в данном конкретном случае, возможно, и имеет смысл. Я не против, если вы поправите. Спасибо.

(Ответ для Владимир Диденко на комментарий #2)
> (In reply to Vitaly Lipatov from comment #1)
> > Да, vendor для rust нехорошо класть в общий каталог: его надо паковать в
> > отдельный тарбол.
> > Если нужно, могу сделать на свой лад.
> 
> Для чистых rust (и, например, go) пакетов я не соглашусь, в данном
Дело в том, что каталог с исходниками в репозитории должен содержать распакованный тарбол, и вы не имеете права его модифицировать. Конечно, если кто-то поставляет тарбол уже с vendor, тут вопросов нет.

(In reply to Vitaly Lipatov from comment #3)
> Дело в том, что каталог с исходниками в репозитории должен содержать
> распакованный тарбол, и вы не имеете права его модифицировать. 

А почему не имею права?

(Ответ для Владимир Диденко на комментарий #4)
> (In reply to Vitaly Lipatov from comment #3)
> > Дело в том, что каталог с исходниками в репозитории должен содержать
> > распакованный тарбол, и вы не имеете права его модифицировать. 
> 
> А почему не имею права?
Потому что это нарушение правил.
Содержимое каталога должно обновляться из апстримного тарбола. Меняя там что-то вручную, вы скрываете свои изменения.
Я уж не говорю, что другой мантейнер при попытке обновить такой пакет столкнётся с проблемами.

(In reply to Vitaly Lipatov from comment #5)
> Потому что это нарушение правил.

Ну вот меня и интересует, каких именно правил? Я не из вредности спрашиваю, а чтобы разобраться. У меня есть несколько go-пакетов, в которых vendor лежит в основной папке. И знаю немало немоих пакетов, которые используют тот же самый принцип. Поэтому, прежде чем бежать все переделывать, хочу разобраться в вопросе.

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

Они не скрываются. Импорт/обновление vendor производится отдельным коммитом. И все изменения лежат в папке vendor. Это сложно назвать скрытием.

(Ответ для Владимир Диденко на комментарий #6)
> (In reply to Vitaly Lipatov from comment #5)
> > Потому что это нарушение правил.
> 
> Ну вот меня и интересует, каких именно правил? Я не из вредности спрашиваю,
> а чтобы разобраться. У меня есть несколько go-пакетов, в которых vendor
> лежит в основной папке. И знаю немало немоих пакетов, которые используют тот
> же самый принцип. Поэтому, прежде чем бежать все переделывать, хочу
> разобраться в вопросе.
Лучше паковать vendor в отдельный тарбол (из отдельного каталога, отдельным правилом в .gear/rules — для этого там есть параметры name= и base=).
Тогда всё будет наглядно. И может быть, надо появится информация, как этот vendor обновлять.

(In reply to Vitaly Lipatov from comment #7)
> (Ответ для Владимир Диденко на комментарий #6)
> > (In reply to Vitaly Lipatov from comment #5)
> > > Потому что это нарушение правил.
> > 
> > Ну вот меня и интересует, каких именно правил? Я не из вредности спрашиваю,
> > а чтобы разобраться. У меня есть несколько go-пакетов, в которых vendor
> > лежит в основной папке. И знаю немало немоих пакетов, которые используют тот
> > же самый принцип. Поэтому, прежде чем бежать все переделывать, хочу
> > разобраться в вопросе.
> Лучше паковать vendor в отдельный тарбол (из отдельного каталога, отдельным
> правилом в .gear/rules — для этого там есть параметры name= и base=).
> Тогда всё будет наглядно. И может быть, надо появится информация, как этот
> vendor обновлять.

Заранее прошу прощения за дотошность. Но все-таки хотелось бы разобраться.

1. В данном конкретном случае я могу понять, почему отдельный tarball лучше, поскольку vendor директория спрятана внутрях. А вот дальше не совсем ясно.

2. В чистых rust и go пакетах vendor директория лежит на самом первом уровне, и для всех кто знаком со сборкой rust и go пакетов не является секетом не назначение директории, ни процесс ее обновления. Упаковка vendor директории в отдельный tar архив тут только запутывает. По крайней мере, на мой взгляд.

3. Но судя по комментариям выше есть момент нарушения каких-то правил/договоренностей/лицензий? Вот это самый непонятный для меня вопрос.

(Ответ для Владимир Диденко на комментарий #8)
...
> Заранее прошу прощения за дотошность. Но все-таки хотелось бы разобраться.
Без проблем.

> 1. В данном конкретном случае я могу понять, почему отдельный tarball лучше,
> поскольку vendor директория спрятана внутрях. А вот дальше не совсем ясно.
Отдельный тарбол лучше потому, что каталог с исходниками должен формироваться простой распаковкой апстримного тарбола и никак иначе.
 
> 2. В чистых rust и go пакетах vendor директория лежит на самом первом
> уровне, и для всех кто знаком со сборкой rust и go пакетов не является
> секетом не назначение директории, ни процесс ее обновления. Упаковка vendor
> директории в отдельный tar архив тут только запутывает. По крайней мере, на
> мой взгляд.
Вы ещё не признались, где вы берёте этот vendor.
Я всё спрашиваю в контексте существования
https://www.altlinux.org/Etersoft-build-utils/extra_sources
который направлен на автоматическое обновление скачиваемых компонент типа vendor.

> 3. Но судя по комментариям выше есть момент нарушения каких-то
> правил/договоренностей/лицензий? Вот это самый непонятный для меня вопрос.
Ну я же объяснил, что в каталог распаковывается апстримный тарбол.
Обычно это делают командой
gear-update
которая используется и в etersoft-build-utils (в команде rpmgs или rpmrb, которые обновляют исходники до новой версии)

Наверное, будет понятнее, если я напишу, что не нужно думать, что в каталог кладутся файлы, из которых собирается пакет. В каталог распаковывается исходный тарбол без изменений. Дополнительные изменения делаются добавлением патчей (для исправления кода) или добавлением архивов (в случае необходимости добавить что-то стороннее).

(In reply to Vitaly Lipatov from comment #9)

> Вы ещё не признались, где вы берёте этот vendor.
> Я всё спрашиваю в контексте существования
> https://www.altlinux.org/Etersoft-build-utils/extra_sources
> который направлен на автоматическое обновление скачиваемых компонент типа
> vendor.

$ cargo vendor

> 
> > 3. Но судя по комментариям выше есть момент нарушения каких-то
> > правил/договоренностей/лицензий? Вот это самый непонятный для меня вопрос.
> Ну я же объяснил, что в каталог распаковывается апстримный тарбол.
> Обычно это делают командой
> gear-update
> которая используется и в etersoft-build-utils (в команде rpmgs или rpmrb,
> которые обновляют исходники до новой версии)

gear-update не единственный способ обновить исходники. Еще раз, в данном конкретном случае, я согласен, что лучше сделать отдельный tarball. Но обычно в наших rust и go пакетах импортится апстримовский git и сорцы обновляются через git merge.  Вот в этом конкретном случае непонятно, зачем нужно вытаскивать vendor в отдельное место.

(Ответ для Владимир Диденко на комментарий #10)
...
> gear-update не единственный способ обновить исходники. Еще раз, в данном
> конкретном случае, я согласен, что лучше сделать отдельный tarball. Но
> обычно в наших rust и go пакетах импортится апстримовский git и сорцы
А где можно почитать об этом способе? Чтобы я попробовал повторить на каком-то конкретном пакете.

> обновляются через git merge.  Вот в этом конкретном случае непонятно, зачем
> нужно вытаскивать vendor в отдельное место.
Да, в этом случае там уже и так получается репозиторий-солянка, никакого смысла отделять vendor нет, равно как и собирать из апстримного репозитория.

python3-module-cryptography-3.4.7-alt1 -> sisyphus:

 Sun Apr 25 2021 Vitaly Lipatov <lav@altlinux.ru> 3.4.7-alt1
 - new version (3.4.7) with rpmgs script (ALT bug 39889)
 - update src/rust/vendor separately

(In reply to Vitaly Lipatov from comment #11)
> А где можно почитать об этом способе? Чтобы я попробовал повторить на
> каком-то конкретном пакете.
> 

Если именно Rust пакеты интересуют, то можно глянуть на ripgrep (пакет не мой)

http://git.altlinux.org/gears/r/ripgrep.git

Если Go, то fzf (пакет мой)

http://git.altlinux.org/gears/f/fzf.git

(Ответ для Владимир Диденко на комментарий #13)
> (In reply to Vitaly Lipatov from comment #11)
> > А где можно почитать об этом способе? Чтобы я попробовал повторить на
> > каком-то конкретном пакете.
> > 
> 
> Если именно Rust пакеты интересуют, то можно глянуть на ripgrep (пакет не
> мой)
> 
> http://git.altlinux.org/gears/r/ripgrep.git
> 
> Если Go, то fzf (пакет мой)
> 
> http://git.altlinux.org/gears/f/fzf.git
Ага, спасибо.