[devel] abstract TeX dependencies

[devel] abstract TeX dependencies

[Kirill Maslinsky]

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

Всем привет!

Есть предложение по урегулированию зависимостей для организации
плавного перехода tetex->texlive, поскольку tetex не поддерживается, 
а texlive поддерживается и развивается.

Я вижу тут такие задачи: 
- необходимо постепенно, но полностью перевести пакеты, использующие
  ТеХ для сборки, на texlive
- необходимо сделать возможным установку пакетов, по сути независимых
  от дистрибутива ТеХ, как с tetex, так и с texlive

Идея в том, что чтобы никого не загонять палками в светлое будущее, 
нужно сделать выбор того или иного дистрибутива ТеХ максимально гибким.

Для этого предлагаю организовать виртуальные пакеты, предоставляющие
обобщённую ТеХовскую функциональность и использовать именно такие 
обобщённые зависимости в сборочных и установочных заивисимостях пакетов, 
вместо tetex-* или texlive-*

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

1. /usr/bin/latex, /usr/bin/dvips etc.
	
	Такие пути автоматически провайдят пакеты, содержащие соотв. бинарники.

	В этом случае мы предоставляем apt'у выбирать, какие конкретно
	пакеты использовать (из tetex или из texlive), допуская, что 
	пакет, содержащий исполняемый файл, напр. latex, будет содержать
	также и всё необходимое для "стандартной" компиляции. 

	apt будет выбирать, кстати, не знаю по какому принципу (лексикографический
	порядок?), но сейчас он при прочих равных выберет texlive.

2. tex(latex), tex(pdflatex) etc.

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

	Есть ли какая-то техническая разница между обычными виртуальными
	пакетами (см. п. 3) и такими зависимостями (со скобками?)

3. latex-minimal, pdflatex-minimal etc.

	Можно сделать такие виртуальные пакеты, в зависимости к которым можно 
	поставить эмпирически подобранное множество пакетов, необходимое для
	реализации соотв. функции (скажем, сборки документации в стандартном латехе). 

	Зависимости виртуальных пакетов можно формировать как в терминах 
	конкретных пакетов (texlive-latex-base etc.), так и в терминах более
	абстрактных (напр., файловых) зависимостей.

PS Кстати, вроде бы упоминалось, что где-то доступны в простом текстовом
виде актуальные спеки всех пакетов Сизифа, удобные для грепа? 
Очень бы сейчас пригодилось для выявления пакетов, зависящих от tetex.

-- 
Kirill Maslinsky
ALT Linux Team

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

Re: [devel] abstract TeX dependencies

[Alexey Tourbin]

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

On Tue, Mar 17, 2009 at 12:57:13PM +0300, Kirill Maslinsky wrote:
> Есть предложение по урегулированию зависимостей для организации
> плавного перехода tetex->texlive, поскольку tetex не поддерживается, 
> а texlive поддерживается и развивается.
> 
> Я вижу тут такие задачи: 
> - необходимо постепенно, но полностью перевести пакеты, использующие
>   ТеХ для сборки, на texlive

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

Для BuildRequires не нужны очень гибкие зависимости.
Как правило, в BuildRequires следует указывать имена настоящих пакетов.
Это то, что делает buildreq.

> - необходимо сделать возможным установку пакетов, по сути независимых
>   от дистрибутива ТеХ, как с tetex, так и с texlive

Это более актуальная задача, потому что tetex и texlive конфликтуют.
Поэтому зависимости Requires должны быть более гибкими.

> Идея в том, что чтобы никого не загонять палками в светлое будущее, 
> нужно сделать выбор того или иного дистрибутива ТеХ максимально гибким.
> 
> Для этого предлагаю организовать виртуальные пакеты, предоставляющие
> обобщённую ТеХовскую функциональность и использовать именно такие 
> обобщённые зависимости в сборочных и установочных заивисимостях пакетов, 
> вместо tetex-* или texlive-*
> 
> Есть варианты, как могут выглядеть такие обобщённые зависимости, хочу
> посоветоваться, какой лучше выбрать:
> 
> 1. /usr/bin/latex, /usr/bin/dvips etc.

Для зависимостей Requires это предпочтительный вариант.
Такие зависимости сейчас генерируются автоматически.

> 	Такие пути автоматически провайдят пакеты, содержащие соотв. бинарники.
> 
> 	В этом случае мы предоставляем apt'у выбирать, какие конкретно
> 	пакеты использовать (из tetex или из texlive),

Не только apt сможет выбирать, но в идеале и пользователь сможет
сменить дистрибутив tex (apt-get install tetex-core- texlive-base).

>	допуская, что 
> 	пакет, содержащий исполняемый файл, напр. latex, будет содержать
> 	также и всё необходимое для "стандартной" компиляции. 

Я ещё не смотрел, как распилен texlive, но у меня есть подозрение, что он
странно распилен, потому что главный пакет с командами получается *-bin
подпакетом.  Тогда возникает вопрос, какой из подпакетов главный, и кто
кого должен требовать.  И чья работоспособность от кого должна зависеть.

> 	apt будет выбирать, кстати, не знаю по какому принципу (лексикографический
> 	порядок?), но сейчас он при прочих равных выберет texlive.

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

> 2. tex(latex), tex(pdflatex) etc.
> 
> 	Вместо автоматически полученных файловых зависимостей, можно сделать 
> 	другие абстрактные зависимости, более точно описывающие заявленную 
> 	функциональность. 

Что означает зависимость tex(latex)?  "Хорошие" зависимости, как
правило, сводятся к файлам.  Если сведение зависимости к файлу не
создает двусмысленности, то это предпочтительный вариант.  Если же
появляется двусмысленность, то используется пространство имён со
скобками, напр. perl(File/Find.pm), это означает, что файл File/Find.pm
может находиться в одном из нескольких стандартных каталогов.
Другой пример: для сонеймов стандартный каталог просто отрезается.

Если речь идёт о latex, то здесь есть двусмысленность по пакетам (tetex
vs texlive), но нет двусмысленности по пути -- /usr/bin/latex.  Поэтому
лучше всего использовать путь к файлу как основную форму зависимости,
если речь идёт о программе "latex".

Другое дело, если речь идёт не просто о программе "latex", а о
подсистеме latex.  Но зависимости на файлы (и вообще "хорошие"
зависимости, которые сводятся к файлам) можно искать автоматически,
а зависимости на подсистемы, если они не сводятся к конкретным файлам,
автоматически проставить очень сложно.  А это значит нужно бегать с
палкой за мейнтейнерами и объяснять им где чего нужно написать.

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

> 	Есть ли какая-то техническая разница между обычными виртуальными
> 	пакетами (см. п. 3) и такими зависимостями (со скобками?)

Давайте определимся, что называть виртуальными пакетами.  Виртуальный
пакет -- это зависимость, у которого нет одноименного *.rpm пакета
(установленного в rpmdb).  В этом смысле зависимости со скобками -- это
как раз виртуальные пакеты, а пакеты типа latex-minimal -- это настоящие
пакеты, потому что они устанавливаются в rpmdb, хотя у них и пустой
список файлов.

> 3. latex-minimal, pdflatex-minimal etc.
> 
> 	Можно сделать такие виртуальные пакеты, в зависимости к которым можно 
> 	поставить эмпирически подобранное множество пакетов, необходимое для
> 	реализации соотв. функции (скажем, сборки документации в стандартном латехе). 
> 
> 	Зависимости виртуальных пакетов можно формировать как в терминах 
> 	конкретных пакетов (texlive-latex-base etc.), так и в терминах более
> 	абстрактных (напр., файловых) зависимостей.

Мне не очень нравятся *-minimal пакеты-пустышки, которые транслируют
зависимости.  Зависимости должны быть непосредственными и конкретными:
если конечному пакету что-то нужно для своей работы, то он должен
содержать непосредственную зависимость в некоем "конкретном" виде.

> PS Кстати, вроде бы упоминалось, что где-то доступны в простом текстовом
> виде актуальные спеки всех пакетов Сизифа, удобные для грепа? 
> Очень бы сейчас пригодилось для выявления пакетов, зависящих от tetex.

Если есть доступ на сервер то спеки извлекаются через rpmpeek.
Упражнение на несколько минут.

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

Re: [devel] abstract TeX dependencies

[Alexander Borovsky]

Hello

2009/3/17 Kirill Maslinsky <kirill@>:
> Всем привет!
>
> Есть предложение по урегулированию зависимостей для организации
> плавного перехода tetex->texlive, поскольку tetex не поддерживается,
> а texlive поддерживается и развивается.
>
Пока существует кроме зависимостей ещё одна грабля при миграции: в
texlive сейчас /usr/share/texmf/doc это symlink. Поэтому мы не имеем
права в него класть документацию в пакетах (но очень хочется, ибо это
стандартный путь к документации ТеХа)

-- 
With best regards,
Alexander Borovsky

JID: belpartizan@jabber.ru

Re: [devel] abstract TeX dependencies

[Michael Pozhidaev]

Hello, Alexey Tourbin!

>> 1. /usr/bin/latex, /usr/bin/dvips etc.
>
> Для зависимостей Requires это предпочтительный вариант.
> Такие зависимости сейчас генерируются автоматически.

Есть некоторые случаи, когда требуется только наличие некоторых
директорий, чтобы туда положить расширения tex, соблюдая возможность
пользователя самому выбрать tetex/texlive.
Какой из путей более правильный/возможный:
1.  включить все подобные директории в отдельный общий пакет, который
может жить вместе с любым дистрибутивом tex. Сейчас есть tex-common, но
kirill@ говорит, что включить туда *все* директории, которые могут
понадобится не так просто. Если я не правильно усёк проблему, пусть
kirill@ скажет это точнее;

2. иметь какую-нибудь виртуальную зависимость (которая не ставится в
rpmdb и разрешается через provides), удовлетворяя которую появляются все
нужные директории, но удовлетворить её могут как tetex, так и texlive.

3. указать в requires прямо имя директории. Сейчас попробовал попросить
apt разрешить такую зависимость при установленном texlive. так он
собрался texlive вообще удалить, что не подходило бы по замыслу.

[msp@blard ~]$ rpm -qa | grep texlive | sort
texlive-base-2008.0-alt0.9.1
texlive-base-bin-2008.0-alt0.9
texlive-common-0.1-alt1
texlive-doc-base-2008.0-alt0.9
texlive-extra-utils-2008.0-alt0.9
texlive-fonts-recommended-2008.0-alt0.9.1
texlive-font-utils-2008.0-alt0.9
texlive-lang-cyrillic-2008.0-alt0.9.1
texlive-latex-base-2008.0-alt0.9.1
texlive-latex-recommended-2008.0-alt0.9.1
texlive-math-extra-2008.0-alt0.9
texlive-metapost-2008.0-alt0.9
texlive-omega-2008.0-alt0.9
texlive-publishers-2008.0-alt0.9
texlive-science-2008.0-alt0.9

[msp@blard ~]$ sudo apt-get install /usr/share/texmf/fonts
Reading Package Lists... Done
Building Dependency Tree... Done
Selecting tetex-core for '/usr/share/texmf/fonts'
The following extra packages will be installed:
  tetex-core
The following packages will be REMOVED:
  ghostscript-utils kde kdegraphics kdegraphics-kdvi texlive-base
  texlive-base-bin texlive-extra-utils texlive-font-utils
  texlive-fonts-recommended texlive-lang-cyrillic texlive-latex-base
  texlive-latex-recommended texlive-math-extra texlive-metapost texlive-omega
  texlive-publishers texlive-science
The following NEW packages will be installed:
  tetex-core
0 upgraded, 1 newly installed, 17 removed and 509 not upgraded.
Need to get 20.2MB of archives.
After unpacking 228MB disk space will be freed.
Do you want to continue? [Y/n] 
-- 
Michael Pozhidaev. E-mail: msp@altlinux.ru.
Tomsk State University. http://www.csd.tsu.ru
ALT Linux Team. http://www.altlinux.org

Re: [devel] abstract TeX dependencies

[Grigory Batalov]

On Wed, Mar 18, 2009 at 03:57:50PM +0200, Alexander Borovsky wrote:
> > Есть предложение по урегулированию зависимостей для организации
> > плавного перехода tetex->texlive, поскольку tetex не поддерживается,
> > а texlive поддерживается и развивается.
> >
> Пока существует кроме зависимостей ещё одна грабля при миграции: в
> texlive сейчас /usr/share/texmf/doc это symlink. Поэтому мы не имеем
> права в него класть документацию в пакетах (но очень хочется, ибо это
> стандартный путь к документации ТеХа)

Очевидно, решение сделать texmf/doc ссылкой было ошибочным.
Предлагаю вернуть папку и включить её в tex-common.

Re: [devel] abstract TeX dependencies

[Kirill Maslinsky]

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

On Wed, Mar 18, 2009 at 03:57:50PM +0200, Alexander Borovsky wrote:
> Hello
> 
> 2009/3/17 Kirill Maslinsky <kirill@>:
> > Всем привет!
> >
> > Есть предложение по урегулированию зависимостей для организации
> > плавного перехода tetex->texlive, поскольку tetex не поддерживается,
> > а texlive поддерживается и развивается.
> >
> Пока существует кроме зависимостей ещё одна грабля при миграции: в
> texlive сейчас /usr/share/texmf/doc это symlink. Поэтому мы не имеем
> права в него класть документацию в пакетах (но очень хочется, ибо это
> стандартный путь к документации ТеХа)

Это была наша ошибка при сборке texlive. Я сейчас могу сделать это
обратно каталогом (отдав его пакету, видимо, tex-common), и выкинуть
симлинк из всех texlive-пакетов. Думал, просто, стоит ли выкладывать
весь texlive ради одного этого изменения, но может быть и стоит. 
По крайней мере auctex уже самому очень хочется использовать :)

-- 
Kirill Maslinsky
ALT Linux Team

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

Re: [devel] abstract TeX dependencies

[Kirill Maslinsky]

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

On Wed, Mar 18, 2009 at 06:59:18PM +0300, Kirill Maslinsky wrote:
> On Wed, Mar 18, 2009 at 03:57:50PM +0200, Alexander Borovsky wrote:
> > Hello
> > 
> > 2009/3/17 Kirill Maslinsky <kirill@>:
> > > Всем привет!
> > >
> > > Есть предложение по урегулированию зависимостей для организации
> > > плавного перехода tetex->texlive, поскольку tetex не поддерживается,
> > > а texlive поддерживается и развивается.
> > >
> > Пока существует кроме зависимостей ещё одна грабля при миграции: в
> > texlive сейчас /usr/share/texmf/doc это symlink. Поэтому мы не имеем
> > права в него класть документацию в пакетах (но очень хочется, ибо это
> > стандартный путь к документации ТеХа)
> 
> Это была наша ошибка при сборке texlive. Я сейчас могу сделать это
> обратно каталогом (отдав его пакету, видимо, tex-common), и выкинуть
> симлинк из всех texlive-пакетов. Думал, просто, стоит ли выкладывать
> весь texlive ради одного этого изменения, но может быть и стоит. 
> По крайней мере auctex уже самому очень хочется использовать :)

2bga@: Гриша, может быть ты это сделаешь быстрее? Тогда давай :)

-- 
Kirill Maslinsky
ALT Linux Team

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

Re: [devel] abstract TeX dependencies

[Kirill Maslinsky]

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

On Wed, Mar 18, 2009 at 08:45:51PM +0600, Michael Pozhidaev wrote:
> Hello, Alexey Tourbin!
> 
> >> 1. /usr/bin/latex, /usr/bin/dvips etc.
> >
> > Для зависимостей Requires это предпочтительный вариант.
> > Такие зависимости сейчас генерируются автоматически.
> 
> Есть некоторые случаи, когда требуется только наличие некоторых
> директорий, чтобы туда положить расширения tex, соблюдая возможность
> пользователя самому выбрать tetex/texlive.
> Какой из путей более правильный/возможный:
> 1.  включить все подобные директории в отдельный общий пакет, который
> может жить вместе с любым дистрибутивом tex. Сейчас есть tex-common, но
> kirill@ говорит, что включить туда *все* директории, которые могут
> понадобится не так просто. Если я не правильно усёк проблему, пусть
> kirill@ скажет это точнее;

Поясню: сложность там в том, что разным сторонним пакетам,
предоставляющим стилевые файлы, шрифты и пр., нужно класть файлы 
в целый ряд подкаталогов /usr/share/texmf, согласно TDS. 
Все эти подкаталоги запакованы сейчас в tetex-core и в кучу 
texlive-пакетов. Чтобы выкинуть их из tetex, нужно его пересобрать.
Чтобы выкинуть их из texlive-*, нужно его тоже пересобрать, 
но там списки файлов пакетов генерятся автоматически, списки надо
аккуратно перегенерить, и там могут быть нюансы (тут bga@ лучше знает).

В целом, я пока не уверен, что это вообще правильный путь -- переносить, 
по существу, все стандартные подкаталоги /usr/share/texmf в tex-common. 
Но других вариантов пока тоже не вижу.

-- 
Kirill Maslinsky
ALT Linux Team

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

Re: [devel] abstract TeX dependencies

[Mikhail Gusarov]

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


Twas brillig at 19:06:25 18.03.2009 UTC+03 when kirill@altlinux.org did gyre and gimble:

 KM> В целом, я пока не уверен, что это вообще правильный путь --
 KM> переносить, по существу, все стандартные подкаталоги
 KM> /usr/share/texmf в tex-common.

Если стандартные подкаталоги /usr/share/texmf являются общими для
нескольких реализаций, то это наиболее правильный выход.

-- 

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

Re: [devel] abstract TeX dependencies

[Kirill Maslinsky]

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

On Wed, Mar 18, 2009 at 10:07:42PM +0600, Mikhail Gusarov wrote:
> 
> Twas brillig at 19:06:25 18.03.2009 UTC+03 when kirill@altlinux.org did gyre and gimble:
> 
>  KM> В целом, я пока не уверен, что это вообще правильный путь --
>  KM> переносить, по существу, все стандартные подкаталоги
>  KM> /usr/share/texmf в tex-common.
> 
> Если стандартные подкаталоги /usr/share/texmf являются общими для
> нескольких реализаций, то это наиболее правильный выход.

Если следовать логике дебиановского ТеХ-полиси, то каждый дистрибутив
ТеХа должен держать свои файлы в особом texmf-дереве (TEXMFDIST), скажем, 
/usr/share/texmf-texlive. Для texlive это верно, а вот наш tetex
держит файлы по старинке в /usr/shre/texmf.

Дерево же /usr/share/texmf предназначено, по новой схеме, как раз 
для файлов сторонних пакетов, т.к. файлы из этого дерева "затеняют"
дистрибутивные TEXMFDIST, что позволяет не трогая дистрибутив ТеХа,
предоставить, например, отдельный стиль более новой версии. 

-- 
Kirill Maslinsky
ALT Linux Team

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

Re: [devel] abstract TeX dependencies

[Mikhail Gusarov]

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


Twas brillig at 19:13:01 18.03.2009 UTC+03 when kirill@altlinux.org did gyre and gimble:

 KM> Дерево же /usr/share/texmf предназначено, по новой схеме, как раз
 KM> для файлов сторонних пакетов

В этом случае - тем более, это кросс-дистрибутивные директории и должны
лежать в каком-нибудь tex-common или tex-support.

-- 

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

Re: [devel] abstract TeX dependencies

[Kirill Maslinsky]

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

On Tue, Mar 17, 2009 at 03:29:06PM +0300, Alexey Tourbin wrote:
> On Tue, Mar 17, 2009 at 12:57:13PM +0300, Kirill Maslinsky wrote:
> > Есть предложение по урегулированию зависимостей для организации
> > плавного перехода tetex->texlive, поскольку tetex не поддерживается, 
> > а texlive поддерживается и развивается.
> > 
> > Я вижу тут такие задачи: 
> > - необходимо постепенно, но полностью перевести пакеты, использующие
> >   ТеХ для сборки, на texlive
> 
> Это менее актуальная задача.  Пока существуют tetex и texlive,
> достаточно, чтобы пакет собирался в одной из конфигураций.
> Переход на сборку с texlive должен выполнить мейнтейнер.

Согласен. Тогда эта задача снимается, что всем упрощает жизнь.

> > - необходимо сделать возможным установку пакетов, по сути независимых
> >   от дистрибутива ТеХ, как с tetex, так и с texlive
> 
> Это более актуальная задача, потому что tetex и texlive конфликтуют.
> Поэтому зависимости Requires должны быть более гибкими.

> > 1. /usr/bin/latex, /usr/bin/dvips etc.
> 
> Для зависимостей Requires это предпочтительный вариант.
> Такие зависимости сейчас генерируются автоматически.

ОК. Значит ли это, что если пакет просто использует какие-то
программы из ТеХа, а не является частью самого дистрибутива ТеХа, 
то следует удалить из установочных зависимостей tetex-* и texlive-* ?

Могут ли быть случаи, в которых нужно явное указание зависимости 
вида /sr/bin/latex ? 

> > 	Такие пути автоматически провайдят пакеты, содержащие соотв. бинарники.
> > 
> > 	В этом случае мы предоставляем apt'у выбирать, какие конкретно
> > 	пакеты использовать (из tetex или из texlive),
> 
> Не только apt сможет выбирать, но в идеале и пользователь сможет
> сменить дистрибутив tex (apt-get install tetex-core- texlive-base).
В том смысле, что при смене tetex  на texlive апт не вынесет все 
зависимые пакеты? Так да, за это и боремся :)

> >	допуская, что 
> > 	пакет, содержащий исполняемый файл, напр. latex, будет содержать
> > 	также и всё необходимое для "стандартной" компиляции. 
> 
> Я ещё не смотрел, как распилен texlive, но у меня есть подозрение, что он
> странно распилен, потому что главный пакет с командами получается *-bin
> подпакетом.  Тогда возникает вопрос, какой из подпакетов главный, и кто
> кого должен требовать.  И чья работоспособность от кого должна зависеть.

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

Сейчас по факту подсистему LaTeX предоставляет пакет texlive-latex-base,
он вытягивает texlive-base-bin и texlive-base, без которых латех
полноценно работать не будет.

> > 	apt будет выбирать, кстати, не знаю по какому принципу (лексикографический
> > 	порядок?), но сейчас он при прочих равных выберет texlive.
> 
> Если нет интуитивного понятного и очевидного способа, какой из вариантов
> должен быть выбран, то не следует полагаться на apt, что он найдёт и
> предложит именно такой способ.

Ну, в общем, я не против того, чтобы апт вёл себя как сейчас и выбирал 
при прочих равных texlive :)
>
> > 2. tex(latex), tex(pdflatex) etc.
> > 
> > 	Вместо автоматически полученных файловых зависимостей, можно сделать 
> > 	другие абстрактные зависимости, более точно описывающие заявленную 
> > 	функциональность. 
> 
> Что означает зависимость tex(latex)?  "Хорошие" зависимости, как
> правило, сводятся к файлам.  Если сведение зависимости к файлу не
> создает двусмысленности, то это предпочтительный вариант.  Если же
> появляется двусмысленность, то используется пространство имён со
> скобками, напр. perl(File/Find.pm), это означает, что файл File/Find.pm
> может находиться в одном из нескольких стандартных каталогов.
> Другой пример: для сонеймов стандартный каталог просто отрезается.
> 
> Если речь идёт о latex, то здесь есть двусмысленность по пакетам (tetex
> vs texlive), но нет двусмысленности по пути -- /usr/bin/latex.  Поэтому
> лучше всего использовать путь к файлу как основную форму зависимости,
> если речь идёт о программе "latex".
> 
> Другое дело, если речь идёт не просто о программе "latex", а о
> подсистеме latex.  Но зависимости на файлы (и вообще "хорошие"
> зависимости, которые сводятся к файлам) можно искать автоматически,
> а зависимости на подсистемы, если они не сводятся к конкретным файлам,
> автоматически проставить очень сложно.  А это значит нужно бегать с
> палкой за мейнтейнерами и объяснять им где чего нужно написать.

Да, проще, конечно, обеспечить, чтобы пакет, предоставляющий
/usr/bin/latex, всегда предоставлял полноценную подсистему LaTeX,
а не просто голый бинарник. Наверное, даже стоит принять это за правило
и записать в полиси.

[...]

> > 3. latex-minimal, pdflatex-minimal etc.
> > 
> > 	Можно сделать такие виртуальные пакеты, в зависимости к которым можно 
> > 	поставить эмпирически подобранное множество пакетов, необходимое для
> > 	реализации соотв. функции (скажем, сборки документации в стандартном латехе). 
> > 
> > 	Зависимости виртуальных пакетов можно формировать как в терминах 
> > 	конкретных пакетов (texlive-latex-base etc.), так и в терминах более
> > 	абстрактных (напр., файловых) зависимостей.
> 
> Мне не очень нравятся *-minimal пакеты-пустышки, которые транслируют
> зависимости.  Зависимости должны быть непосредственными и конкретными:
> если конечному пакету что-то нужно для своей работы, то он должен
> содержать непосредственную зависимость в некоем "конкретном" виде.

ОК, от этого варианта отказываемся.

> > PS Кстати, вроде бы упоминалось, что где-то доступны в простом текстовом
> > виде актуальные спеки всех пакетов Сизифа, удобные для грепа? 
> > Очень бы сейчас пригодилось для выявления пакетов, зависящих от tetex.
> 
> Если есть доступ на сервер то спеки извлекаются через rpmpeek.
> Упражнение на несколько минут.

Ага, спасибо, попробую.

-- 
Kirill Maslinsky
ALT Linux Team

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

Re: [devel] abstract TeX dependencies

[Mikhail Gusarov]

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


Twas brillig at 19:43:17 18.03.2009 UTC+03 when kirill@altlinux.org did gyre and gimble:

 KM> Да, проще, конечно, обеспечить, чтобы пакет, предоставляющий
 KM> /usr/bin/latex, всегда предоставлял полноценную подсистему LaTeX, а
 KM> не просто голый бинарник. Наверное, даже стоит принять это за
 KM> правило и записать в полиси.

Это не нужно. Если в пакете есть /usr/bin/latex и после установки этого
пакета /usr/bin/latex не работает - это баг в пакете даже без
дополнительных полиси.

-- 

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

Re: [devel] abstract TeX dependencies

[Grigory Batalov]

On Wed, Mar 18, 2009 at 07:06:25PM +0300, Kirill Maslinsky wrote:
> > Есть некоторые случаи, когда требуется только наличие некоторых
> > директорий, чтобы туда положить расширения tex, соблюдая возможность
> > пользователя самому выбрать tetex/texlive.
> > Какой из путей более правильный/возможный:
> > 1.  включить все подобные директории в отдельный общий пакет, который
> > может жить вместе с любым дистрибутивом tex. Сейчас есть tex-common, но
> > kirill@ говорит, что включить туда *все* директории, которые могут
> > понадобится не так просто. Если я не правильно усёк проблему, пусть
> > kirill@ скажет это точнее;
> 
> Поясню: сложность там в том, что разным сторонним пакетам,
> предоставляющим стилевые файлы, шрифты и пр., нужно класть файлы 
> в целый ряд подкаталогов /usr/share/texmf, согласно TDS. 
> Все эти подкаталоги запакованы сейчас в tetex-core и в кучу 
> texlive-пакетов. Чтобы выкинуть их из tetex, нужно его пересобрать.
> Чтобы выкинуть их из texlive-*, нужно его тоже пересобрать, 
> но там списки файлов пакетов генерятся автоматически, списки надо
> аккуратно перегенерить, и там могут быть нюансы (тут bga@ лучше знает).
> 
> В целом, я пока не уверен, что это вообще правильный путь -- переносить, 
> по существу, все стандартные подкаталоги /usr/share/texmf в tex-common. 
> Но других вариантов пока тоже не вижу.

Я что-то потерял нить.
Зачем выносить все директории в общий пакет? Недавно же писали,
что одинаковые директории можно включать в несколько пакетов,
последний удаляемый заберёт их с собой.

Re: [devel] abstract TeX dependencies

[Kirill Maslinsky]

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

On Wed, Mar 18, 2009 at 09:01:34PM +0300, Grigory Batalov wrote:

[...]

> > Поясню: сложность там в том, что разным сторонним пакетам,
> > предоставляющим стилевые файлы, шрифты и пр., нужно класть файлы 
> > в целый ряд подкаталогов /usr/share/texmf, согласно TDS. 
> > Все эти подкаталоги запакованы сейчас в tetex-core и в кучу 
> > texlive-пакетов. Чтобы выкинуть их из tetex, нужно его пересобрать.
> > Чтобы выкинуть их из texlive-*, нужно его тоже пересобрать, 
> > но там списки файлов пакетов генерятся автоматически, списки надо
> > аккуратно перегенерить, и там могут быть нюансы (тут bga@ лучше знает).
> > 
> > В целом, я пока не уверен, что это вообще правильный путь -- переносить, 
> > по существу, все стандартные подкаталоги /usr/share/texmf в tex-common. 
> > Но других вариантов пока тоже не вижу.
> 
> Я что-то потерял нить.
> Зачем выносить все директории в общий пакет? Недавно же писали,
> что одинаковые директории можно включать в несколько пакетов,
> последний удаляемый заберёт их с собой.

В том-то и дело, что если каталоги будут принадлежать сразу нескольким 
несвязанным пакетам (tetex, texlive, стили из сторонних пакетов), то 
каталоги там будут с одним и тем же именем, но не будут уже совпадать
с точностью до mtime (так как эти каталоги взяты не из одного исходника). 
Правильно я понимаю, что эту ситуацию rpm уже будет рассматривать как
конфликт?

-- 
Kirill Maslinsky
ALT Linux Team

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

Re: [devel] abstract TeX dependencies

[Igor Vlasenko]

On Wed, Mar 18, 2009 at 09:44:04PM +0300, Kirill Maslinsky wrote:
> В том-то и дело, что если каталоги будут принадлежать сразу нескольким 
> несвязанным пакетам (tetex, texlive, стили из сторонних пакетов), то 
> каталоги там будут с одним и тем же именем, но не будут уже совпадать
> с точностью до mtime (так как эти каталоги взяты не из одного исходника). 
> Правильно я понимаю, что эту ситуацию rpm уже будет рассматривать как
> конфликт?

нет.
Вот если бы права отличались или группа,...

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] abstract TeX dependencies

[Michael Pozhidaev]

Hello, Igor Vlasenko!

> нет.
> Вот если бы права отличались или группа,...
ТОгда надо договорится, как сформулировать Requires для сторонних
расширений, чтобы для них аккуратно устанавливался бы один из
дистрибутивов TeX, а в случае необходимости его можно было бы сменить.
Остаются два варианта:
1. прямо указывается имя директории. Как приводил в пред. письме, сейчас
просьба apt'у установить /usr/share/texmf/fonts приводит к удалению
texlive и установке tetex, чего не должно быть;

2. указывается какой-нибудь виртуальный пакет, который вписан в
Provides: как в tetex, так и в texlive.

-- 
Michael Pozhidaev. E-mail: msp@altlinux.ru.
Tomsk State University. http://www.csd.tsu.ru
ALT Linux Team. http://www.altlinux.org

Re: [devel] abstract TeX dependencies

[Alexey Tourbin]

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

On Wed, Mar 18, 2009 at 08:45:51PM +0600, Michael Pozhidaev wrote:
> >> 1. /usr/bin/latex, /usr/bin/dvips etc.
> >
> > Для зависимостей Requires это предпочтительный вариант.
> > Такие зависимости сейчас генерируются автоматически.
> 
> Есть некоторые случаи, когда требуется только наличие некоторых
> директорий, чтобы туда положить расширения tex, соблюдая возможность
> пользователя самому выбрать tetex/texlive.

При установке rpm автоматически создает недостающие промежуточные
каталоги.  С другой стороны, это создает проблему "ничейных каталогов".
Эту проблему сложно решить хорошо без преумножения сущностей.
Иерархия вложенности каталогов фс не всегда хорошо согласуется
с упорядоченностью зависимостей.  Иначе можно договориться
до того, что все пакеты, которые что-то требуют, должны лежать
в подкаталогах относительно тех пакетов, которые они требуют.
Но этот расклад по смыслу не всегда выполняется.

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

> Какой из путей более правильный/возможный:
> 1.  включить все подобные директории в отдельный общий пакет, который
> может жить вместе с любым дистрибутивом tex. Сейчас есть tex-common, но
> kirill@ говорит, что включить туда *все* директории, которые могут
> понадобится не так просто. Если я не правильно усёк проблему, пусть
> kirill@ скажет это точнее;

Забейте на эту проблему (пока).  Её можно решить очень строго и совершенно
автоматически: для каждого файла в пакете ставить зависимость на
родительский каталог.  Но мы получим слишком жесткие и нежелательные
зависимости.  Чтобы побороть жесткие и нежелательные зависимости,
придётся у многих пакетов отпиливать базовый пакет-пустышку, который
владеет каталогами.  Я сомневаюсь, что это нужно делать, и что это
реально что-то решает.

> 2. иметь какую-нибудь виртуальную зависимость (которая не ставится в
> rpmdb и разрешается через provides), удовлетворяя которую появляются все
> нужные директории, но удовлетворить её могут как tetex, так и texlive.

Это искусственное решение искусственной проблемы.
Реальной проблемы нет (реальная проблема -- это работоспособность
пакетов, и зависимости пакетов, которые должны обеспечивать
работоспособность).

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

> 3. указать в requires прямо имя директории.

Для конечных пакетов это самое простое и правильное решение.

> Сейчас попробовал попросить
> apt разрешить такую зависимость при установленном texlive. так он
> собрался texlive вообще удалить, что не подходило бы по замыслу.

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

> [msp@blard ~]$ sudo apt-get install /usr/share/texmf/fonts
> Reading Package Lists... Done
> Building Dependency Tree... Done
> Selecting tetex-core for '/usr/share/texmf/fonts'

Зависимости /usr/share/texmf/fonts в базе апта нету.

$ $TMPDIR/build/aptbox/apt-cache showpkg /usr/share/texmf/fonts
W: Unable to locate package /usr/share/texmf/fonts
$

apt-get выбрал эту зависимость через pkgRecords, то есть через просмотр
списков %{FILENAMES} в pkglist.classic.bz2.  Выбор через pkgRecords
работает только через командную строку.

$ bzcat /ALT/Sisyphus/{i586,noarch}/base/pkglist.classic.bz2 |./pkglist-query '[%{=NAME}\t%{=ARCH}\t%{FILENAMES}\n]' - |awk '$3=="/usr/share/texmf/fonts"'
tetex-core      i586    /usr/share/texmf/fonts
texlive-base-bin        i586    /usr/share/texmf/fonts
texlive-font-utils      i586    /usr/share/texmf/fonts
$ 

Короче, смысл в этом такой:
1) когда на командной строке говорят 'install foo'; и
2) когда апт рекурсивно разрешает зависимости пакетов; то
работают два совершенно разных алгоритма.
Первый алгоритм называется TryToInstall, а второй -- MarkInstall.

То есть когда Вы сказали 'install /usr/share/texmf/fonts', то по
результату нельзя судить, что будет, если пакет будет содержать
зависимость на /usr/share/texmf/fonts.

> The following extra packages will be installed:
>   tetex-core
> The following packages will be REMOVED:
>   ghostscript-utils kde kdegraphics kdegraphics-kdvi texlive-base
>   texlive-base-bin texlive-extra-utils texlive-font-utils
>   texlive-fonts-recommended texlive-lang-cyrillic texlive-latex-base
>   texlive-latex-recommended texlive-math-extra texlive-metapost texlive-omega
>   texlive-publishers texlive-science
> The following NEW packages will be installed:
>   tetex-core
> 0 upgraded, 1 newly installed, 17 removed and 509 not upgraded.

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

Re: [devel] abstract TeX dependencies

[Alexey Tourbin]

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

On Wed, Mar 18, 2009 at 09:44:04PM +0300, Kirill Maslinsky wrote:
> > > Поясню: сложность там в том, что разным сторонним пакетам,
> > > предоставляющим стилевые файлы, шрифты и пр., нужно класть файлы 
> > > в целый ряд подкаталогов /usr/share/texmf, согласно TDS. 
> > > Все эти подкаталоги запакованы сейчас в tetex-core и в кучу 
> > > texlive-пакетов. Чтобы выкинуть их из tetex, нужно его пересобрать.
> > > Чтобы выкинуть их из texlive-*, нужно его тоже пересобрать, 
> > > но там списки файлов пакетов генерятся автоматически, списки надо
> > > аккуратно перегенерить, и там могут быть нюансы (тут bga@ лучше знает).
> > > 
> > > В целом, я пока не уверен, что это вообще правильный путь -- переносить, 
> > > по существу, все стандартные подкаталоги /usr/share/texmf в tex-common. 
> > > Но других вариантов пока тоже не вижу.
> > 
> > Я что-то потерял нить.
> > Зачем выносить все директории в общий пакет? Недавно же писали,
> > что одинаковые директории можно включать в несколько пакетов,
> > последний удаляемый заберёт их с собой.
> 
> В том-то и дело, что если каталоги будут принадлежать сразу нескольким 
> несвязанным пакетам (tetex, texlive, стили из сторонних пакетов), то 
> каталоги там будут с одним и тем же именем, но не будут уже совпадать
> с точностью до mtime (так как эти каталоги взяты не из одного исходника). 
> Правильно я понимаю, что эту ситуацию rpm уже будет рассматривать как
> конфликт?

Нет, конфликта не будет.
Код файлового конфликта в rpm менялся, актуальным следует считать вот этот код.

lib/transaction.c:
   884  static int filecmp(const TFI_t fi1, const int ix1, const TFI_t fi2, const int ix2)
   885          /*@*/
   886  {
   887      uint_16 m1 = fi1->fmodes[ix1], m2 = fi2->fmodes[ix2];
   888      uint_32 f1 = fi1->fflags[ix1], f2 = fi2->fflags[ix2];
   889      const char *u1 = fi1->fuser[ix1], *u2 = fi2->fuser[ix2];
   890      const char *g1 = fi1->fgroup[ix1], *g2 = fi2->fgroup[ix2];
   891  
   892      /* both file type and permissions must match */
   893      if (m1 != m2)
   894          return 1;
   895  
   896      /* ownership must also match */
   897      if (strcmp(u1, u2) || strcmp(g1, g2))
   898          return 1;
   899  
   900      if ((f1 | f2) & RPMFILE_GHOST)
   901          /* one or both %ghost files, no extra check */
   902          ;
   903      else if (S_ISLNK(m1)) {
   904          /* symlinks must have the same target */
   905          const char *l1 = fi1->flinks[ix1], *l2 = fi2->flinks[ix2];
   906          if (strcmp(l1, l2))
   907              return 1;
   908      }
   909      else if (S_ISREG(m1)) {
   910          /* regular files must have the same md5 sum */
   911          const char *md51 = fi1->fmd5s[ix1], *md52 = fi2->fmd5s[ix2];
   912          if (strcmp(md51, md52))
   913              return 1;
   914      }
   915  
   916      /* e.g. mtime difference is immaterial */
   917      return 0;
   918  }

Но кроме файлового конфликта есть ещё rpmverify.
Уточнить поведение 'rpm -Vv' с ходу не берусь.

То есть получается что один каталог расшарен с разным mtime.  Что не
фатально, но как бы немножко остается вопрос, какой mtime считать
правильным.

Впрочем, mtime каталога -- очень хрупкая вещь; mtime каталога
автоматически меняется, когда в каталоге создаются или удаляются файлы.
Проверять mtime каталога смысла очень мало.

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

Re: [devel] abstract TeX dependencies

[Grigory Batalov]

On Thu, Mar 19, 2009 at 03:15:21AM +0600, Michael Pozhidaev wrote:

> > нет.
> > Вот если бы права отличались или группа,...
> ТОгда надо договорится, как сформулировать Requires для сторонних
> расширений, чтобы для них аккуратно устанавливался бы один из
> дистрибутивов TeX, а в случае необходимости его можно было бы сменить.

Так и надо ставить Requires на дистрибутив TeX, а не на директорию.
Если же нужен не дистрибутив, а абстрактный latex, то на
/usr/bin/latex , как писал Кирилл в соседней ветке.

> Остаются два варианта:
> 1. прямо указывается имя директории. Как приводил в пред. письме, сейчас
> просьба apt'у установить /usr/share/texmf/fonts приводит к удалению
> texlive и установке tetex, чего не должно быть;
> 
> 2. указывается какой-нибудь виртуальный пакет, который вписан в
> Provides: как в tetex, так и в texlive.

Re: [devel] abstract TeX dependencies

[Alexey Tourbin]

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

On Wed, Mar 18, 2009 at 07:43:17PM +0300, Kirill Maslinsky wrote:
> > > - необходимо сделать возможным установку пакетов, по сути независимых
> > >   от дистрибутива ТеХ, как с tetex, так и с texlive
> > 
> > Это более актуальная задача, потому что tetex и texlive конфликтуют.
> > Поэтому зависимости Requires должны быть более гибкими.
> 
> > > 1. /usr/bin/latex, /usr/bin/dvips etc.
> > 
> > Для зависимостей Requires это предпочтительный вариант.
> > Такие зависимости сейчас генерируются автоматически.
> 
> ОК. Значит ли это, что если пакет просто использует какие-то
> программы из ТеХа, а не является частью самого дистрибутива ТеХа, 
> то следует удалить из установочных зависимостей tetex-* и texlive-* ?

Да.

> Могут ли быть случаи, в которых нужно явное указание зависимости 
> вида /sr/bin/latex ? 

Если эта зависимость на найдена автоматически.

Сейчас при сборке в хешере на удаленном репозитарии (без contents_index)
зависимость либо не будет найдена, либо будет найдена неправильно.

> > >	допуская, что 
> > > 	пакет, содержащий исполняемый файл, напр. latex, будет содержать
> > > 	также и всё необходимое для "стандартной" компиляции. 
> > 
> > Я ещё не смотрел, как распилен texlive, но у меня есть подозрение, что он
> > странно распилен, потому что главный пакет с командами получается *-bin
> > подпакетом.  Тогда возникает вопрос, какой из подпакетов главный, и кто
> > кого должен требовать.  И чья работоспособность от кого должна зависеть.
> 
> Распилено почти так же, как в дебиане. Мне тоже распил кажется
> неоптимальным, готов выслушать обоснованные предложения. 
> 
> Сейчас по факту подсистему LaTeX предоставляет пакет texlive-latex-base,
> он вытягивает texlive-base-bin и texlive-base, без которых латех
> полноценно работать не будет.

Но buildreq какую зависимость будет считать основной?
Это зависит от того, какие файлы используются.
В общем, посмотрим.

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

Re: [devel] abstract TeX dependencies

[Michael Pozhidaev]

Hello, Alexey Tourbin!

> Короче, не следует преувеличивать эту проблему, и не следует делать её
> главным аргументом как распилить пакеты и какие должны быть зависимости.
> Конечно, если есть очевидное и инуитивное решение для конкретного
> случая, то это решение надо реализовать.  Создание пакета-пустышки,
> который владеет каталогом -- это преумножение сущеностей; такое решение
> не относится к очевидному и интуитивному, но, в принципе, это возможное
> решение.
Понятно, в общем проблема соизмеримости лекарства лечимой
болезни. Спасибо за подробный рассказ. Оставим пока как есть, сейчас
проверну распил lilypond-tex, и если он нормально будет ставится на
texlive, а особых причин не ставится у него не должно быть, то пускай
так и остаётся (то есть вообще без вписывания дополнительных
зависимостей).
-- 
Michael Pozhidaev. E-mail: msp@altlinux.ru.
Tomsk State University. http://www.csd.tsu.ru
ALT Linux Team. http://www.altlinux.org

Re: [devel] abstract TeX dependencies

[Денис Смирнов]

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

On Thu, Mar 19, 2009 at 01:32:38AM +0300, Алексей Турбин wrote:

AT> То есть получается что один каталог расшарен с разным mtime.  Что не
AT> фатально, но как бы немножко остается вопрос, какой mtime считать
AT> правильным.

Тот который больше, думаю.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

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

[devel] grab all specfiles

[Alexey Tourbin]

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

On Wed, Mar 18, 2009 at 07:43:17PM +0300, Kirill Maslinsky wrote:
> > > PS Кстати, вроде бы упоминалось, что где-то доступны в простом текстовом
> > > виде актуальные спеки всех пакетов Сизифа, удобные для грепа? 
> > > Очень бы сейчас пригодилось для выявления пакетов, зависящих от tetex.
> > 
> > Если есть доступ на сервер то спеки извлекаются через rpmpeek.
> > Упражнение на несколько минут.
> 
> Ага, спасибо, попробую.

$ mkdir $TMPDIR/specs
$ cd $TMPDIR/specs
$ for f in /ALT/Sisyphus/files/SRPMS/*.src.rpm; do rpmpeek $f sh -c "cp -p *.spec $PWD/"; done

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

Re: [devel] rpm file conflicts

[Kirill Maslinsky]

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

On Wed, Mar 18, 2009 at 08:52:48PM +0200, Igor Vlasenko wrote:
> On Wed, Mar 18, 2009 at 09:44:04PM +0300, Kirill Maslinsky wrote:
> > В том-то и дело, что если каталоги будут принадлежать сразу нескольким 
> > несвязанным пакетам (tetex, texlive, стили из сторонних пакетов), то 
> > каталоги там будут с одним и тем же именем, но не будут уже совпадать
> > с точностью до mtime (так как эти каталоги взяты не из одного исходника). 
> > Правильно я понимаю, что эту ситуацию rpm уже будет рассматривать как
> > конфликт?
> 
> нет.
> Вот если бы права отличались или группа,...
В таком случае нужно исправить в тексте
http://www.altlinux.org/Filesystem_coherency_and_conflicts

"Наличие в разных пакетах одинаковых с точностью до mtime файлов и
каталогов с точки зрения rpm конфликтом не является. "
    
Именно эта фраза вызвала мой вопрос о конфликте каталогов 
из-за замечания "с точностью до mtime". Что, кстати, и не соответствует
действительности, как мы выяснили, по крайней мере применительно к
каталогам (про файлы не говорилось в этом контексте). 



> 
> -- 
> 
> Dr. Igor Vlasenko
> --------------------
> Topology Department
> Institute of Math
> Kiev, Ukraine
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

Re: [devel] grab all specfiles

[Igor Vlasenko]

On Tue, Mar 24, 2009 at 07:37:14PM +0300, Alexey Tourbin wrote:
> On Wed, Mar 18, 2009 at 07:43:17PM +0300, Kirill Maslinsky wrote:
> > > > PS Кстати, вроде бы упоминалось, что где-то доступны в простом текстовом
> > > > виде актуальные спеки всех пакетов Сизифа, удобные для грепа? 
> > > > Очень бы сейчас пригодилось для выявления пакетов, зависящих от tetex.

Сорри, пропустил письмо.
Вручную можно не извлекать, 
ежедневно на
http://repocop.altlinux.org/pub/repocop/data/repocop-specfiles-current.tar.gz
выкладывается свежий экстракт.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] rpm file conflicts

[Igor Vlasenko]

On Tue, Mar 24, 2009 at 09:07:21PM +0300, Kirill Maslinsky wrote:
> В таком случае нужно исправить в тексте
> http://www.altlinux.org/Filesystem_coherency_and_conflicts
> 
> "Наличие в разных пакетах одинаковых с точностью до mtime файлов и
> каталогов с точки зрения rpm конфликтом не является. "
>     
> Именно эта фраза вызвала мой вопрос о конфликте каталогов 
> из-за замечания "с точностью до mtime". Что, кстати, и не соответствует
> действительности, как мы выяснили, по крайней мере применительно к
> каталогам (про файлы не говорилось в этом контексте). 

Гм, не совсем понимаю, в чем проблема.

например, когда пишется "с точностью до знака" -
это означает, что все равно, какой знак.

если там написано, "с точностью до mtime" то 
это означает, что все равно, какой mtime.

Что не так?

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] rpm file conflicts

[Kirill Maslinsky]

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

On Tue, Mar 24, 2009 at 09:27:42PM +0200, Igor Vlasenko wrote:
> On Tue, Mar 24, 2009 at 09:07:21PM +0300, Kirill Maslinsky wrote:
> > В таком случае нужно исправить в тексте
> > http://www.altlinux.org/Filesystem_coherency_and_conflicts
> > 
> > "Наличие в разных пакетах одинаковых с точностью до mtime файлов и
> > каталогов с точки зрения rpm конфликтом не является. "
> >     
> > Именно эта фраза вызвала мой вопрос о конфликте каталогов 
> > из-за замечания "с точностью до mtime". Что, кстати, и не соответствует
> > действительности, как мы выяснили, по крайней мере применительно к
> > каталогам (про файлы не говорилось в этом контексте). 
> 
> Гм, не совсем понимаю, в чем проблема.
> 
> например, когда пишется "с точностью до знака" -
> это означает, что все равно, какой знак.
> 
> если там написано, "с точностью до mtime" то 
> это означает, что все равно, какой mtime.
> 
> Что не так?
А! Просто я непривычен к математическому языку, и понял 
это выражение как "mtime должен совпадать". Может быть, 
вставить в формулировку пояснение для непривычных:

"Наличие в разных пакетах одинаковых с точностью до mtime  файлов и
каталогов  с точки зрения rpm конфликтом не является. (т.е.  владелец, группа и права должны совпадать) "

-- 
Kirill Maslinsky

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

Re: [devel] rpm file conflicts

[Artem Zolochevskiy]

2009/3/24 Kirill Maslinsky <kirill@altlinux.org>:
>> Гм, не совсем понимаю, в чем проблема.
>>
>> например, когда пишется "с точностью до знака" -
>> это означает, что все равно, какой знак.
>>
>> если там написано, "с точностью до mtime" то
>> это означает, что все равно, какой mtime.
>>
>> Что не так?
> А! Просто я непривычен к математическому языку, и понял
> это выражение как "mtime должен совпадать". Может быть,
> вставить в формулировку пояснение для непривычных:
>

Этот оборот я понял как и Кирилл как "mtime должен совпадать".
Т.е. +1 за перефразировку для таких непривычных как я.

-- 
Артём Золочевский

Re: [devel] grab all specfiles

[Kirill Maslinsky]

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

On Tue, Mar 24, 2009 at 09:23:28PM +0200, Igor Vlasenko wrote:
> On Tue, Mar 24, 2009 at 07:37:14PM +0300, Alexey Tourbin wrote:
> > On Wed, Mar 18, 2009 at 07:43:17PM +0300, Kirill Maslinsky wrote:
> > > > > PS Кстати, вроде бы упоминалось, что где-то доступны в простом текстовом
> > > > > виде актуальные спеки всех пакетов Сизифа, удобные для грепа? 
> > > > > Очень бы сейчас пригодилось для выявления пакетов, зависящих от tetex.
> 
> Сорри, пропустил письмо.
> Вручную можно не извлекать, 
> ежедневно на
> http://repocop.altlinux.org/pub/repocop/data/repocop-specfiles-current.tar.gz
> выкладывается свежий экстракт.
Большое спасибо, эту-то ссылку я и искал!
Может стоит занести её на вики, только не придумал, 
в какой раздел.

-- 
Kirill Maslinsky

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

Re: [devel] rpm file conflicts

[Igor Vlasenko]

On Tue, Mar 24, 2009 at 09:41:33PM +0200, Artem Zolochevskiy wrote:
> > А! Просто я непривычен к математическому языку, и понял
> > это выражение как "mtime должен совпадать". Может быть,
> > вставить в формулировку пояснение для непривычных:
> >
> 
> Этот оборот я понял как и Кирилл как "mtime должен совпадать".
> Т.е. +1 за перефразировку для таких непривычных как я.

Добавил на wiki пояснение Кирилла.
Кашу маслом не испортишь.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] grab all specfiles

[Michael Shigorin]

On Tue, Mar 24, 2009 at 10:42:09PM +0300, Kirill Maslinsky wrote:
> > http://repocop.altlinux.org/pub/repocop/data/repocop-specfiles-current.tar.gz
> Большое спасибо, эту-то ссылку я и искал!  Может стоит занести
> её на вики, только не придумал, в какой раздел.

/Repocop?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/