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 --]
next prev 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