[devel] buildreq proposal

[devel] buildreq proposal

[Mikhail Zabaluev]

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

Доброго времени суток.

После упражнений с SGML у меня родилась мысль, что в buildreq можно
добавить новые способы поиска зависимостей, поскольку во многих
ситуациях, во-первых, анализ доступа к файлам неадекватен, во-вторых,
есть надежные формальные методы определения зависимостей. При работе с
SGML/XML это вывод системных идентификаторов (то есть имен файлов) из
публичных идентификаторов. Пока не вник, возможно ли для этого
воспользоваться готовым инструментарием. Поскольку документации такого
рода в GNOME уже достаточно много, имеет смысл уделить внимание.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
He's like a function -- he returns a value, in the form of his opinion.
It's up to you to cast it into a void or not.
		-- Phil Lapsley

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

Re: [devel] buildreq proposal

[Ivan Zakharyaschev]

On Mon, 9 Jul 2001, Mikhail Zabaluev wrote:

> Доброго времени суток.
>
> После упражнений с SGML у меня родилась мысль, что в buildreq можно
> добавить новые способы поиска зависимостей, поскольку во многих
> ситуациях, во-первых, анализ доступа к файлам неадекватен, во-вторых,
> есть надежные формальные методы определения зависимостей. При работе
> с
> SGML/XML это вывод системных идентификаторов (то есть имен файлов) из
> публичных идентификаторов. Пока не вник, возможно ли для этого

А почему в этом случае анализ доступ к файлам не адекватен? Если в
системе, где происходит сборка, установлен пакет, предоставляющий
"SGML-объекты" с нужными публичными идентификаторами, то при сборке
SGML-процессор выведет из них системные и совершит доступ к
соответствующему файлу. А файл принадлежит пакету, который и попадет в
зависимости.

Другое дело, если нужного SGML-объекта нет... но в аналогичных случаях с
header-файлами из *-devel пакетов buildreq тоже бессилен: если пакета не
стоит, то и зависимость обнаружена не будет. packager обычно в силах
понять, что не хватает каких-то headers или SGML-объекта.

По-моему, от отслеживания доступа к файлам для получения зависимостей
при сборке отказываться не следует, и ничем усложнять его не надо: он
прост и универсален.

> воспользоваться готовым инструментарием. Поскольку документации

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

-- 
Best regards,
	Ivan Z.

_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

[devel] Re: buildreq proposal

[Mikhail Zabaluev]

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

Hello Ivan,

On Mon, Jul 09, 2001 at 02:16:20AM +0400, Ivan Zakharyaschev wrote:
>
> On Mon, 9 Jul 2001, Mikhail Zabaluev wrote:
> 
> > Доброго времени суток.
> >
> > После упражнений с SGML у меня родилась мысль, что в buildreq можно
> > добавить новые способы поиска зависимостей, поскольку во многих
> > ситуациях, во-первых, анализ доступа к файлам неадекватен, во-вторых,
> > есть надежные формальные методы определения зависимостей. При работе
> > с
> > SGML/XML это вывод системных идентификаторов (то есть имен файлов) из
> > публичных идентификаторов. Пока не вник, возможно ли для этого
> 
> А почему в этом случае анализ доступ к файлам не адекватен? Если в
> системе, где происходит сборка, установлен пакет, предоставляющий
> "SGML-объекты" с нужными публичными идентификаторами, то при сборке
> SGML-процессор выведет из них системные и совершит доступ к
> соответствующему файлу. А файл принадлежит пакету, который и попадет в
> зависимости.
> 
> Другое дело, если нужного SGML-объекта нет... но в аналогичных случаях с
> header-файлами из *-devel пакетов buildreq тоже бессилен: если пакета не
> стоит, то и зависимость обнаружена не будет. packager обычно в силах
> понять, что не хватает каких-то headers или SGML-объекта.
> 
> По-моему, от отслеживания доступа к файлам для получения зависимостей
> при сборке отказываться не следует, и ничем усложнять его не надо: он
> прост и универсален.

У меня сложилось впечатление, что jade ищет по каталогам в
поисках нужного публичного идентификатора. Соответственно в BuildRequires
попадают пачки лишних DTD и stylesheets.

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

Есть ли такой режим, где просто выводятся имена затребованных системных ID
и ничего не делается?

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
Except for 75% of the women, everyone in the whole world wants to have sex.
- Ellyn Mustard

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

Re: [devel] Re: buildreq proposal

[Ivan Zakharyaschev]

	Hello, Mikhail!

On Mon, 9 Jul 2001, Mikhail Zabaluev wrote:

> > > После упражнений с SGML у меня родилась мысль, что в buildreq
> можно
> > > добавить новые способы поиска зависимостей, поскольку во многих
> > > ситуациях, во-первых, анализ доступа к файлам неадекватен,

> > А почему в этом случае анализ доступ к файлам не адекватен? Если в

> У меня сложилось впечатление, что jade ищет по каталогам в
> поисках нужного публичного идентификатора. Соответственно в
> BuildRequires
> попадают пачки лишних DTD и stylesheets.

Да, действительно, нехорошо получается.

И аналогия с headers неполная:  там-то аналогом каталога является
директория, и ее filereq легко отбросит. А каталоги для SGML вроде как с
виду обычные файлы, и называться могут как угодно... хотя можно сказать,
что как правило они называются catalog, и отфильтровывать файлы с такими
именами при анализе вывода strace. Криво это? Может годиться как
врменная мера.

> > А чем openjade не подходящий инструментарий? Он ведь вчера,

Тепрь-то я уже не думаю, что он совсем подходящий.

> Есть ли такой режим, где просто выводятся имена затребованных
> системных ID
> и ничего не делается?

Я такого не обнаружил. Хотелось бы, чтобы он не только они одни
выдавались, а они бы параллельно со обычной сборкой куда-то
записывались. Можно попробовать внести такие усовершенствования -- API
библиотеки openjade описан.

-- 
Best regards,
	Ivan Z.

_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

[devel] Re: buildreq proposal

[Mikhail Zabaluev]

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

Hello Ivan,

On Mon, Jul 09, 2001 at 11:53:28PM +0400, Ivan Zakharyaschev wrote:
>
> > У меня сложилось впечатление, что jade ищет по каталогам в
> > поисках нужного публичного идентификатора. Соответственно в
> > BuildRequires
> > попадают пачки лишних DTD и stylesheets.
> 
> Да, действительно, нехорошо получается.
> 
> И аналогия с headers неполная:  там-то аналогом каталога является
> директория, и ее filereq легко отбросит. А каталоги для SGML вроде как с
> виду обычные файлы, и называться могут как угодно... хотя можно сказать,
> что как правило они называются catalog, и отфильтровывать файлы с такими
> именами при анализе вывода strace. Криво это? Может годиться как
> врменная мера.
> 
> > > А чем openjade не подходящий инструментарий? Он ведь вчера,
> 
> Тепрь-то я уже не думаю, что он совсем подходящий.
> 
> > Есть ли такой режим, где просто выводятся имена затребованных
> > системных ID
> > и ничего не делается?
> 
> Я такого не обнаружил. Хотелось бы, чтобы он не только они одни
> выдавались, а они бы параллельно со обычной сборкой куда-то
> записывались. Можно попробовать внести такие усовершенствования -- API
> библиотеки openjade описан.

В-общем, нужен особый подход.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
Q:	What's the difference between USL and the Titanic?
A:	The Titanic had a band.

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