ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Kirill Maslinsky <kirill@altlinux.org>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] abstract TeX dependencies
Date: Wed, 18 Mar 2009 19:43:17 +0300
Message-ID: <20090318164317.GG24277@localhost.localdomain> (raw)
In-Reply-To: <20090317122906.GP9773@altlinux.org>

[-- 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 --]

  parent reply	other threads:[~2009-03-18 16:43 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-17  9:57 Kirill Maslinsky
2009-03-17 12:29 ` Alexey Tourbin
2009-03-18 14:45   ` Michael Pozhidaev
2009-03-18 16:06     ` Kirill Maslinsky
2009-03-18 16:07       ` Mikhail Gusarov
2009-03-18 16:13         ` Kirill Maslinsky
2009-03-18 16:16           ` Mikhail Gusarov
2009-03-18 18:01       ` Grigory Batalov
2009-03-18 18:44         ` Kirill Maslinsky
2009-03-18 18:52           ` Igor Vlasenko
2009-03-18 21:15             ` Michael Pozhidaev
2009-03-18 22:50               ` Grigory Batalov
2009-03-24 18:07             ` [devel] rpm file conflicts Kirill Maslinsky
2009-03-24 19:27               ` Igor Vlasenko
2009-03-24 19:38                 ` Kirill Maslinsky
2009-03-24 19:41                   ` Artem Zolochevskiy
2009-03-24 19:53                     ` Igor Vlasenko
2009-03-18 22:32           ` [devel] abstract TeX dependencies Alexey Tourbin
2009-03-19  0:16             ` Денис Смирнов
2009-03-18 22:18     ` Alexey Tourbin
2009-03-18 23:12       ` Michael Pozhidaev
2009-03-18 16:43   ` Kirill Maslinsky [this message]
2009-03-18 16:46     ` Mikhail Gusarov
2009-03-18 22:51     ` Alexey Tourbin
2009-03-24 16:37     ` [devel] grab all specfiles Alexey Tourbin
2009-03-24 19:23       ` Igor Vlasenko
2009-03-24 19:42         ` Kirill Maslinsky
2009-03-26 13:18           ` Michael Shigorin
2009-03-18 13:57 ` [devel] abstract TeX dependencies Alexander Borovsky
2009-03-18 15:15   ` Grigory Batalov
2009-03-18 15:59   ` Kirill Maslinsky
2009-03-18 16:00     ` Kirill Maslinsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090318164317.GG24277@localhost.localdomain \
    --to=kirill@altlinux.org \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git