[newbies] Vcs, Source, Url fields

[newbies] Vcs, Source, Url fields

[Alexander Lubyagin]

Добрый день.

По теме предыдущей лекции вспомнился такой вопрос.

В чём назначение и различие полей в SPEC:
Url
Source
Source*
Vcs (например, admsasha/libxml2:sisyphus)

Какими опциями gear/hasher/rpm они "подхватываются"?

И ещё, второй вопрос.
Если при сборке "в песочнице" (gear+hasher), configure+make ругается
в процессе сборки на отсутствие команды git ... очевидно, хочет во время 
сборки
что-то динамически "скачать". Но, по итогу, пакет успешно собирается,
т.е. эти downloads были опциональными.
То как принято поступать? Игнорировать, или где-то вести журнал таких 
попыток?

Александр Лубягин

Re: [newbies] Vcs, Source, Url fields

[Anton Farygin]

On 9/13/25 13:38, Alexander Lubyagin wrote:
> Добрый день.
>
> По теме предыдущей лекции вспомнился такой вопрос.
>
> В чём назначение и различие полей в SPEC:
> Url

Информационный тэг. Служит основным способом определения апстрима

> Source
> Source*
Source* используются для распаковки исходников
> Vcs (например, admsasha/libxml2:sisyphus)

Vcs информационный тэг, пока используется только на packages.altlinux.org

тоже служит способом определения апстрима (git'а).

Re: [newbies] Vcs, Source, Url fields

[Paul Wolneykien]

В Sat, 13 Sep 2025 14:58:11 +0300
Anton Farygin <rider@altlinux.org> пишет:

> On 9/13/25 13:38, Alexander Lubyagin wrote:
> > Добрый день.
> >
> > По теме предыдущей лекции вспомнился такой вопрос.
> >
> > В чём назначение и различие полей в SPEC:
> > Url  
> 
> Информационный тэг. Служит основным способом определения апстрима

  Смотря, что понимать под апстримом. К сожалению, у нас сложилась
нехорошая, на мой взгляд, практика, когда в тег "Url:" помещают
непосредственно адрес исходников (к примеру, github или gitlab),
который может не совпадать с главной страницей проекта и
документацией к нему. В то же время, в руководстве к RPM сказано
вот как: "The url tag is used to define a Uniform Resource Locator
that can be used to obtain additional information about the packaged
software". Поэтому я думаю, что данный тег предназначается, в первую
очередь, для пользователя пакета, а не для сопровождающих: когда
пользователю не вполне ясно, что представляет собой данный пакет,
его назначение и т. д., (а %description и упакованного README не
достаточно), пользователь может открыть сайт проекта, взяв адрес
из поля "Url" (это поле отображается в информации о пакете в apt,
synaptic и "магазинах приложений"). А если по данному Url откроется
не сайт проекта, а его исходники, то часть пользователей просто
не пойдёт искать дальше.

> 
> > Source
> > Source*  
> Source* используются для распаковки исходников
> > Vcs (например, admsasha/libxml2:sisyphus)  
> 
> Vcs информационный тэг, пока используется только на packages.altlinux.org
> 
> тоже служит способом определения апстрима (git'а).

  Другое дело --- тег "Vcs:". Вот туда, действительно, имеет смысл
помещать именно прямую ссылку на исходный код.

Re: [newbies] Vcs, Source, Url fields

[Anton Farygin]

On 9/15/25 12:23, Paul Wolneykien wrote:
> В Sat, 13 Sep 2025 14:58:11 +0300
> Anton Farygin <rider@altlinux.org> пишет:
>
>> On 9/13/25 13:38, Alexander Lubyagin wrote:
>>> Добрый день.
>>>
>>> По теме предыдущей лекции вспомнился такой вопрос.
>>>
>>> В чём назначение и различие полей в SPEC:
>>> Url
>> Информационный тэг. Служит основным способом определения апстрима
>    Смотря, что понимать под апстримом. К сожалению, у нас сложилась
> нехорошая, на мой взгляд, практика, когда в тег "Url:" помещают
> непосредственно адрес исходников (к примеру, github или gitlab),
> который может не совпадать с главной страницей проекта и
> документацией к нему. В то же время, в руководстве к RPM сказано
> вот как: "The url tag is used to define a Uniform Resource Locator
> that can be used to obtain additional information about the packaged
> software". Поэтому я думаю, что данный тег предназначается, в первую
> очередь, для пользователя пакета, а не для сопровождающих: когда
> пользователю не вполне ясно, что представляет собой данный пакет,
> его назначение и т. д., (а %description и упакованного README не
> достаточно), пользователь может открыть сайт проекта, взяв адрес
> из поля "Url" (это поле отображается в информации о пакете в apt,
> synaptic и "магазинах приложений"). А если по данному Url откроется
> не сайт проекта, а его исходники, то часть пользователей просто
> не пойдёт искать дальше.

Я же и написал, что для апстрима. Да, это HOMEPAGE проекта, он часто 
совпадает с github/gitlab


>
>>> Source
>>> Source*
>> Source* используются для распаковки исходников
>>> Vcs (например, admsasha/libxml2:sisyphus)
>> Vcs информационный тэг, пока используется только на packages.altlinux.org
>>
>> тоже служит способом определения апстрима (git'а).
>    Другое дело --- тег "Vcs:". Вот туда, действительно, имеет смысл
> помещать именно прямую ссылку на исходный код.
Да

Re: [newbies] Vcs, Source, Url fields

[Leonid Znamenok]

Alexander,

13.09.2025 13:38, Alexander Lubyagin пишет:
> Добрый день.
>
> По теме предыдущей лекции вспомнился такой вопрос.
>
> В чём назначение и различие полей в SPEC:
> Url
> Source
> Source*
> Vcs (например, admsasha/libxml2:sisyphus)
>
> Какими опциями gear/hasher/rpm они "подхватываются"?
>
RPM:
Это часть spec файла. Spec файл обрабатывает rpmbuild. Следовательно,
эти поля "подхватываются" rpmbuild'ом и попадают в метаинформацию rpm
и srpm файлов. Значительную часть это метаинформации можно посмотреть
при помощи команды `rpm -qpi` направленной на rpm/srpm файл.

Здесь:
- q - query, запрос информации о пакете
- p - package_file, указание на обработку файла, а не установленного пакета
- i - info, вывод информации

-i выводит не всю метаинформацию. Полный список хранящихся тегов можно
посмотреть при помощи `rpm --querytags`. Эти теги используются с опцией
`--queryformat`.

Например, команда `rpm -qp --queryformat "%{NAME}: %{VCS}\n" 
some-package.rpm`
выведет имя пакета и значение его поля VCS. Подробнее можно прочитать в 
`man rpm`

GEAR:
Gear так же умеет читать и парсить (до некоторой степени) spec файлы. 
Так, в gear-rules
можно использовать ключевые слова @name@, @version@, @release@, значение
которых будет взято из spec файла.

См. `man gear-rules`

> И ещё, второй вопрос.
> Если при сборке "в песочнице" (gear+hasher), configure+make ругается
> в процессе сборки на отсутствие команды git ... очевидно, хочет во 
> время сборки
> что-то динамически "скачать". Но, по итогу, пакет успешно собирается,
> т.е. эти downloads были опциональными.
> То как принято поступать? Игнорировать, или где-то вести журнал таких 
> попыток? 

В общем случае - необязательно. Часть пакетов пытается сделать `git 
describe` для
того, чтобы сформировать свою версию.

Лучшим решением будет почитать make файлы, и смотреть зачем нужен (и нужен
ли вообще) там бинарник git'а. И исходя из этого уже действовать.

> Александр Лубягин
> _______________________________________________
> devel-newbies mailing list
> devel-newbies@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-newbies

-- 
---
WBR, Leonid (respublica@altlinux.org)

Re: [newbies] Vcs, Source, Url fields

[Leonid Krivoshein]

Доброго времени!


On 9/13/25 13:38, Alexander Lubyagin wrote:
> Добрый день.
>
> По теме предыдущей лекции вспомнился такой вопрос.
>
> В чём назначение и различие полей в SPEC:
> Url
> Source
> Source*
> Vcs (например, admsasha/libxml2:sisyphus)
>

Хорошее начало здесь: https://www.altlinux.org/Join

Там при рекурсивном изучении матчасти обязательно попадутся такие странички:

https://www.altlinux.org/Spec
https://www.altlinux.org/Spec/Предопределенные_макросы


> Какими опциями gear/hasher/rpm они "подхватываются"?
>

Всё же это метаданные RPM/SRPM. Source довольно тесно связан с 
.gear/rules (.gear-rules). Url нужен для идентификации исходного 
проекта, это поле сравнимо с Unique ID и его наличие проверяется 
repocop'ом (https://www.altlinux.org/Repocop), отчёты repocop'а 
выводятся по каждому SRPM: 
https://packages.altlinux.org/ru/sisyphus/srpms/partclone/repocop/


> И ещё, второй вопрос.
> Если при сборке "в песочнице" (gear+hasher), configure+make ругается
> в процессе сборки на отсутствие команды git ...

Значит, проверяйте сборочные зависимости.


> очевидно, хочет во время сборки
> что-то динамически "скачать". Но, по итогу, пакет успешно собирается,
> т.е. эти downloads были опциональными.
> То как принято поступать? Игнорировать, или где-то вести журнал таких 
> попыток?

Предметно нужно смотреть логи и исходники.


-- 
WBR, Leonid Krivoshein.