[devel] full list of unmets

[devel] full list of unmets

[@ 2006-06-19 1:06 UTC (permalink / raw)]

[devel] libldap22? (was: full list of unmets)

[@ 2006-06-19 8:00 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 9:09 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 9:38 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 9:54 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 9:58 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 10:11 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 10:11 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 10:22 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 11:44 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 12:28 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 12:32 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 15:45 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 18:18 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 20:06 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 20:13 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 20:22 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-19 20:38 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 0:04 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 0:17 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 0:55 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 0:58 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 1:15 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 1:32 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 2:02 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 7:23 UTC (permalink / raw)]

[devel] замкнутое подмножество (was: full list of unmets)

[@ 2006-06-20 7:27 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 7:34 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 7:36 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 7:38 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 7:48 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 8:46 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 9:06 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 9:07 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 9:12 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 15:33 UTC (permalink / raw)]

Re: [devel] full list of unmets

[@ 2006-06-20 15:35 UTC (permalink / raw)]

Re: [devel] full list of unmets

[Led]

В сообщении от 20 июня 2006 18:35 Alexey Tourbin написал(a):
> On Tue, Jun 20, 2006 at 11:46:16AM +0300, Led wrote:
> > В сообщении от 20 июня 2006 05:02 Alexey Tourbin написал(a):
> > > On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
> > > > Что касается более сложной обработки, то тут надо вспомнить
> > > > математику и хорошенько подумать.
> > >
> > > Ну в общем да.  Нужно осилить топологию и теорию графов.  Потом нужно
> > > переписать apt на ocaml'е. :)  Сейчас к апту очень серьезная претензия:
> > > библиотека libapt-pkg не дает доступа к основным алгоритмам.  То есть
> > > например алгоритм 'apt-get --print-uris install' закоден
> > > непосредственно в apt-get.  Чтобы попробовать узнать, можно установить
> > > отдельно взятый пакет или нет, приходится запускать apt-get и парсить
> > > его вывод. Каждый такой запуск стоит порядка секунды, а большая часть
> > > времени уходит на чтение/инициализацию кеша.  То есть нельзя достаточно
> > > быстро проверить, какие пакеты в сизифе устанавливаемы, а какие нет. 
> > > Нельзя загрузить кеш один раз и проверить все пакеты в пределах одного
> > > процесса.
> >
> > А разве apt-shell не так делает?
>
> Это несколько облегчает, но не отменяют проблему.

Это была реплика на "Нельзя загрузить кеш один раз и проверить все пакеты в 
пределах одного процесса". Не более того...

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

ИМХО на перле "свет клином не сошёлся".

-- 
Led.

Re: [devel] full list of unmets

[Alexey Tourbin]

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

On Tue, Jun 20, 2006 at 01:07:27PM +0400, Alexey Gladkov wrote:
> > 2) почему плагины так жестко зависят от версии firefox, так что их даже
> > приходится пересобирать при sub-micro изменении версии, очевидно
> > багфиксной?  Кто и зачем придумал такие жесткие зависимости?
> 
> В начале это было необходимо ... сейчас можно не ставить зависимость
> на версию... те кому это нужно могут поставить менее жёсткую зависимость.

Нужно поставить менее жесткую зависимость.  Если цифры в версиях вообще
что-либо означают, то $major.$minor.$micro.$sub_micro нужно понимать так:

1) $micro фиксирует совместимость на уровне интерфейсов;
2) $sub_micro содержит исключительно багфиксы.

Тогда совместимость нужно зафиксировать на уровне $major.$minor, в
данном случае плагины должны зависеть от чего-то вроде firefox_api = 1.5.
Поскольку есть отдельный пакет rpm-build-firefox, этот вопрос можно
решить один раз и надолго для всех плагинов.

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

Re: [devel] full list of unmets

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

On Tue, Jun 20, 2006 at 10:23:53AM +0300, Michael Shigorin wrote:

>> В любом случае, любой сколько-нибудь "волшебный" алгоритм должен был бы
>> зарубить новый firefox, потому что он увеличивает количество анметов.
MS> Алгоритм оказался бы дураком, поскольку нифига не читает даже
MS> bugtraq@ и не в состоянии осознать, что свежий firefox всегда
MS> важнее примочек.

apt-get upgrade оказался бы точно таким же дураком.

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

http://freesource.info
----------------------------------------------------------------------------
Зачем вам понадобился -L/usr/lib?
		-- ldv in sisyphus@

Re: [devel] full list of unmets

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

On Tue, Jun 20, 2006 at 04:17:25AM +0400, Dmitry V. Levin wrote:

DVL> Кстати, если с волшебными алгоритмами ничего не выйдет, может просто
DVL> выделить небольшое подмножество Сизифа, которое будет гарантированно
DVL> замкнутым (например, как Owl)?

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

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

http://freesource.info
----------------------------------------------------------------------------
Какой-то патч страшненький у тебя получился.
		-- ldv in #6099

Re: [devel] full list of unmets

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Tourbin <at@altlinux.ru> writes:
[skipped]
 >> Для этого есть apt-pipe, который вполне реально IMHO научить жить под 
 >> обычным пользователем (создавать сокет в заданном каталоге).

 > Я когда смотрел apt-pipe, он не умел жить под отдельным пользователем,
 > то есть всегда создавал сокет под /var/lib/apt.  Спасибо, посмотрю ещё.

Не умеет и сейчас. Желающие приделать ключик -- да не убоятся.

-- 

Re: [devel] full list of unmets

[Anton Farygin]

Alexey Tourbin wrote:
> On Tue, Jun 20, 2006 at 11:38:35AM +0400, Anton Farygin wrote:
>> Alexey Tourbin wrote:
>>> On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
>>>> Что касается более сложной обработки, то тут надо вспомнить математику и
>>>> хорошенько подумать.
>>> Ну в общем да.  Нужно осилить топологию и теорию графов.  Потом нужно
>>> переписать apt на ocaml'е. :)  Сейчас к апту очень серьезная претензия:
>>> библиотека libapt-pkg не дает доступа к основным алгоритмам.  То есть
>>> например алгоритм 'apt-get --print-uris install' закоден непосредственно
>>> в apt-get.  Чтобы попробовать узнать, можно установить отдельно взятый
>>> пакет или нет, приходится запускать apt-get и парсить его вывод.
>>> Каждый такой запуск стоит порядка секунды, а большая часть времени
>>> уходит на чтение/инициализацию кеша.  То есть нельзя достаточно быстро
>>> проверить, какие пакеты в сизифе устанавливаемы, а какие нет.  Нельзя
>>> загрузить кеш один раз и проверить все пакеты в пределах одного
>>> процесса.
>> Для этого есть apt-pipe, который вполне реально IMHO научить жить под 
>> обычным пользователем (создавать сокет в заданном каталоге).
> 
> Я когда смотрел apt-pipe, он не умел жить под отдельным пользователем,
> то есть всегда создавал сокет под /var/lib/apt.  Спасибо, посмотрю ещё.

Он и сейчас не умеет, но IMHO научить достаточно просто.

Rgds,
Rider

Re: [devel] [JT] full list of unmets

[Ivan Fedorov]

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

Alexey Tourbin пишет:
>>> Элегантное решение существует.  Стоимость элегантного решения прмерно $481.
>> Зипованные доллары принимаете?
> 
> Зип хорошо жмет от $1000.
> 
> $ wc -c <full_unmets
> 972
> $ gzip <full_unmets |wc -c
> 554
> $

А что говорит zme ? :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [devel] full list of unmets

[Dmitry V. Levin]

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

On Tue, Jun 20, 2006 at 07:46:01PM +0400, Денис Смирнов wrote:
> On Tue, Jun 20, 2006 at 04:17:25AM +0400, Dmitry V. Levin wrote:
> 
> DVL> Кстати, если с волшебными алгоритмами ничего не выйдет, может просто
> DVL> выделить небольшое подмножество Сизифа, которое будет гарантированно
> DVL> замкнутым (например, как Owl)?
> 
> Я об этом уже месяц кричу на каждом углу. Только я предлагаю выделять не
> руками, а роботом.

Роботом можно только помогать.  Я говорю о том, что есть небольшое по
меркам Сизифа число пакетов, которые нужны настолько, что люди (а не
только роботы) готовы постоянно держать их в полной готовности.

Таких пакетов не может быть много.


-- 
ldv

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

Re: [devel] full list of unmets

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

On Sun, Jun 25, 2006 at 03:23:41PM +0400, Dmitry V. Levin wrote:
>> Я об этом уже месяц кричу на каждом углу. Только я предлагаю выделять не
>> руками, а роботом.
DVL> Роботом можно только помогать. 

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

DVL> Я говорю о том, что есть небольшое по
DVL> меркам Сизифа число пакетов, которые нужны настолько, что люди (а не
DVL> только роботы) готовы постоянно держать их в полной готовности.
DVL> Таких пакетов не может быть много.

Да, согласен. Но при этом очень хочется иметь репозиторий, в котором все
пакеты и всегда в полной готовности. Или максимально близкой к полной, но
пакеты таки все.

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

http://freesource.info
----------------------------------------------------------------------------
Если программа полностью отлажена, ее нужно будет скорректировать.

Re: [devel] full list of unmets

[Dmitry V. Levin]

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

On Tue, Jun 20, 2006 at 05:32:01AM +0400, Alexey Tourbin wrote:
> On Tue, Jun 20, 2006 at 05:15:00AM +0400, Dmitry V. Levin wrote:
> > В простейшем случае нет отстойника.
> > Например, каждый новый пакет, будучи собранным, образует новый репозиторий
> > Sisyphus, состоящий из всех прежних пакетов минус пакеты, собранные из
> > прежней версии (если были) плюс свежесобранные пакеты.
> 
> Что значит "плюс свежесобранные пакеты"?
> 
> Вот идут подряд пакеты A и B.  Пакет B сборочно-завист от A.  Пакет A не
> удовлетворяет простому алгоритму (т.е. откладывается в "отстойник" --
> решение будет приниматься вручную).  Тогда сборки пакета B на-сизифе и
> на-отстойнике в общем случае не идентичны.  Где собирать пакет B?
> 
> В идеале нельзя собирать пакет B раньше, чем будет принято решение
> по пакету A.  Это особенно важно, если пакеты A и B пришли от одного
> maintainer'а, потому что maintiner таким образом может рассчитывать,
> что пакет B будет собран именно с этим пакетом A.

Я всё же думаю, что в описанной ситуации пакет B следует собирать без учёта
пакета A.  Обоснование простое и состоит из двух частей:
1. Мантейнер может и должен позаботиться о том, чтобы пакет A не попал в
отстойник.  В частности, если имеет место soname change, следует
именовать пакет с библиотекой в духе Debian policy (позаимствованной
оттуда позднее в mdk).
2. Наконец, если это столь важно, мантейнер может добавить строгую
сборочную зависимость.


-- 
ldv

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