[devel] mkimage closure

[devel] mkimage closure

[Alexey Tourbin]

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

У меня концептуальный вопрос по mkimage.  От хорошего инструмента
такого класса требуется два режима замыкания пакетов.

1) Замыкание для мини-дистрибутивов.  Это то что обычно делает apt.
2) Замыкание для "полноценных дистрбиутивов" -- дополнительно
замыкание по всем подпакетам исходного пакета.

Второй режим означает, что если напр. вытянулся perl-base,
а исходный пакет у perl-base называется perl-5.8.X-*.src.rpm,
то дополнительно нужно включить все остальные perl-* пакеты,
которые происходят из этого perl-5.8.X-*.src.rpm.

Ну и концептуальный вопрос простой -- имеется ли ручка для
переключения режимов 1/2 или нет.

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

Re: [devel] mkimage closure

[Aleksey Novodvorsky]

On 11/24/07, Alexey Tourbin <at@altlinux.ru> wrote:
> У меня концептуальный вопрос по mkimage.  От хорошего инструмента
> такого класса требуется два режима замыкания пакетов.
>
> 1) Замыкание для мини-дистрибутивов.  Это то что обычно делает apt.
> 2) Замыкание для "полноценных дистрбиутивов" -- дополнительно
> замыкание по всем подпакетам исходного пакета.
3) Замыкание по сборочным зависимостям.
Зачем нужно 2 мне не совсем понятно.

Rgrds, Алексей
>
> Второй режим означает, что если напр. вытянулся perl-base,
> а исходный пакет у perl-base называется perl-5.8.X-*.src.rpm,
> то дополнительно нужно включить все остальные perl-* пакеты,
> которые происходят из этого perl-5.8.X-*.src.rpm.
>
> Ну и концептуальный вопрос простой -- имеется ли ручка для
> переключения режимов 1/2 или нет.
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>
>

Re: [devel] mkimage closure

[Alexey Tourbin]

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

On Sat, Nov 24, 2007 at 01:07:48AM +0300, Aleksey Novodvorsky wrote:
> On 11/24/07, Alexey Tourbin <at@altlinux.ru> wrote:
> > У меня концептуальный вопрос по mkimage.  От хорошего инструмента
> > такого класса требуется два режима замыкания пакетов.
> >
> > 1) Замыкание для мини-дистрибутивов.  Это то что обычно делает apt.
> > 2) Замыкание для "полноценных дистрбиутивов" -- дополнительно
> > замыкание по всем подпакетам исходного пакета.
> 3) Замыкание по сборочным зависимостям.
> Зачем нужно 2 мне не совсем понятно.

Да, это тоже важно.

Замыкание 2 нужно потому что в полноценные дистрибутивы типа Master
раньше было не принято включать неполные наборы подпакетов исходного
пакета.  То есть была схема src.rpm + всё что из него собралось.

Не должно быть так, что в "полноценный" дистрибутив попадают лишь
некоторые "конъюнктурные" подпакеты.

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

Re: [devel] mkimage closure

[Alexey Gladkov]

Aleksey Novodvorsky wrote:
> 3) Замыкание по сборочным зависимостям.
> Зачем нужно 2 мне не совсем понятно.

Мне тоже не очень понятно зачем это.

Может для того чтобы создавать диски с исходными пакетам ?

-- 
Rgrds, legion

Re: [devel] mkimage closure

[Anton Farygin]

Alexey Tourbin пишет:
> У меня концептуальный вопрос по mkimage.  От хорошего инструмента
> такого класса требуется два режима замыкания пакетов.
> 
> 1) Замыкание для мини-дистрибутивов.  Это то что обычно делает apt.
> 2) Замыкание для "полноценных дистрбиутивов" -- дополнительно
> замыкание по всем подпакетам исходного пакета.
> 
> Второй режим означает, что если напр. вытянулся perl-base,
> а исходный пакет у perl-base называется perl-5.8.X-*.src.rpm,
> то дополнительно нужно включить все остальные perl-* пакеты,
> которые происходят из этого perl-5.8.X-*.src.rpm.

А это действительно необходимо ? Хотя скорее всего было бы неплохо 
получить такой функционал, но реально он может не понадобиться.

Мне хотелось бы видеть в mkimage скорее ручку для добавления 
конфликтующих пакетов... это сложнее ;)

Re: [devel] mkimage closure

[Alexey Tourbin]

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

On Sat, Nov 24, 2007 at 01:11:32AM +0300, Anton Farygin wrote:
> > 1) Замыкание для мини-дистрибутивов.  Это то что обычно делает apt.
> > 2) Замыкание для "полноценных дистрбиутивов" -- дополнительно
> > замыкание по всем подпакетам исходного пакета.
> > 
> > Второй режим означает, что если напр. вытянулся perl-base,
> > а исходный пакет у perl-base называется perl-5.8.X-*.src.rpm,
> > то дополнительно нужно включить все остальные perl-* пакеты,
> > которые происходят из этого perl-5.8.X-*.src.rpm.
> 
> А это действительно необходимо ? Хотя скорее всего было бы неплохо 
> получить такой функционал, но реально он может не понадобиться.

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

> Мне хотелось бы видеть в mkimage скорее ручку для добавления 
> конфликтующих пакетов... это сложнее ;)

Насколько я помню что просматривал git-репозитарий mkimage,
такая идея у автора была и она в какой-то степени реализована.

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

Re: [devel] mkimage closure

[Alexey Gladkov]

Alexey Tourbin wrote:
> Этот функционал нужен не "реально", а "идейно".  В полноценный
> дистрибутив нельзя влючать "огрызки", а только "полный набор".
> Тогда как для мини-дистрибутива реальность другая.

Не думаю что это нельзя реализовать. Пока я таким вопросом не задавался.

> Насколько я помню что просматривал git-репозитарий mkimage,
> такая идея у автора была и она в какой-то степени реализована.

Сейчас такая возможность существует. Реализация этого есть. Есть метод
половинного деления списка пакетов. Не ах как здорово, но ...

-- 
Rgrds, legion

Re: [devel] mkimage closure

[Anton Farygin]

Alexey Gladkov пишет:
> Alexey Tourbin wrote:
>> Этот функционал нужен не "реально", а "идейно".  В полноценный
>> дистрибутив нельзя влючать "огрызки", а только "полный набор".
>> Тогда как для мини-дистрибутива реальность другая.
> 
> Не думаю что это нельзя реализовать. Пока я таким вопросом не задавался.
> 
>> Насколько я помню что просматривал git-репозитарий mkimage,
>> такая идея у автора была и она в какой-то степени реализована.
> 
> Сейчас такая возможность существует. Реализация этого есть. Есть метод
> половинного деления списка пакетов. Не ах как здорово, но ...

А есть возможность копировать все пакеты из репозитариев, за исключением 
списка ?

Т.е. - делать не белый список, а чёрный - только запрещать пакеты из 
репозитария ?

Правда средствами apt'а это реализовать несколько затруднительно (ну 
кроме dump'а, конечно).

Т.е. - когда возникает непреодолимое желание сделать дистрибутив из 
всего branch/4.0, за исключением ms-ttf-fonts и (что б было интереснее) 
- libgnome

Re: [devel] mkimage closure

[Alexey Rusakov]

On Sat, 24 Nov 2007 02:14:22 +0300
Anton Farygin wrote:


> Alexey Gladkov пишет:
> > Alexey Tourbin wrote:
> >> Этот функционал нужен не "реально", а "идейно".  В полноценный
> >> дистрибутив нельзя влючать "огрызки", а только "полный набор".
> >> Тогда как для мини-дистрибутива реальность другая.
> > 
> > Не думаю что это нельзя реализовать. Пока я таким вопросом не задавался.
> > 
> >> Насколько я помню что просматривал git-репозитарий mkimage,
> >> такая идея у автора была и она в какой-то степени реализована.
> > 
> > Сейчас такая возможность существует. Реализация этого есть. Есть метод
> > половинного деления списка пакетов. Не ах как здорово, но ...
> 
> А есть возможность копировать все пакеты из репозитариев, за исключением 
> списка ?
> 
> Т.е. - делать не белый список, а чёрный - только запрещать пакеты из 
> репозитария ?
> 
> Правда средствами apt'а это реализовать несколько затруднительно (ну 
> кроме dump'а, конечно).
> 
> Т.е. - когда возникает непреодолимое желание сделать дистрибутив из 
> всего branch/4.0, за исключением ms-ttf-fonts и (что б было интереснее) 
> - libgnome
Специфическое желание... Здесь нужно довольно-таки фигурно подходить к
выбору запрещаемых пакетов. Иначе есть риск, избегая libgnome, тем не
менее включить в дистрибутив, например, до фига питоновых и перловых
пакетов. Или какую-нибудь тяжёлую игрушку, типа freedroidrpg.
Хотя (только что пришло в голову) в качестве контроля "чистоты" подобное
средство было бы неплохим - например, исключение на *-devel для
не-инструментальных дистрибутивов было бы неплохой идеей.

-- 
  Alexey "Ktirf" Rusakov
  ALT Linux, project manager

Re: [devel] mkimage closure

[Anton Farygin]

Alexey Rusakov пишет:
> On Sat, 24 Nov 2007 02:14:22 +0300
> Anton Farygin wrote:
> 
> 
>> Alexey Gladkov пишет:
>>> Alexey Tourbin wrote:
>>>> Этот функционал нужен не "реально", а "идейно".  В полноценный
>>>> дистрибутив нельзя влючать "огрызки", а только "полный набор".
>>>> Тогда как для мини-дистрибутива реальность другая.
>>> Не думаю что это нельзя реализовать. Пока я таким вопросом не задавался.
>>>
>>>> Насколько я помню что просматривал git-репозитарий mkimage,
>>>> такая идея у автора была и она в какой-то степени реализована.
>>> Сейчас такая возможность существует. Реализация этого есть. Есть метод
>>> половинного деления списка пакетов. Не ах как здорово, но ...
>> А есть возможность копировать все пакеты из репозитариев, за исключением 
>> списка ?
>>
>> Т.е. - делать не белый список, а чёрный - только запрещать пакеты из 
>> репозитария ?
>>
>> Правда средствами apt'а это реализовать несколько затруднительно (ну 
>> кроме dump'а, конечно).
>>
>> Т.е. - когда возникает непреодолимое желание сделать дистрибутив из 
>> всего branch/4.0, за исключением ms-ttf-fonts и (что б было интереснее) 
>> - libgnome
> Специфическое желание... Здесь нужно довольно-таки фигурно подходить к
> выбору запрещаемых пакетов. Иначе есть риск, избегая libgnome, тем не
> менее включить в дистрибутив, например, до фига питоновых и перловых
> пакетов. Или какую-нибудь тяжёлую игрушку, типа freedroidrpg.
> Хотя (только что пришло в голову) в качестве контроля "чистоты" подобное
> средство было бы неплохим - например, исключение на *-devel для
> не-инструментальных дистрибутивов было бы неплохой идеей.

Именно.libgnome - просто пример, причём весьма тяжёлый.

Re: [devel] mkimage closure

[Alexey Rusakov]

(надел противопожарную одежду)

On Sat, 24 Nov 2007 09:11:47 +0300
Anton Farygin wrote:

> Именно.libgnome - просто пример, причём весьма тяжёлый.
JustTalk, но ради прикола, посмотрите на размер libgnome. Возможно, он вас
удивит ;)
Если уж говорить о тяжести GNOME, то это libgnomeui, libbonobo и
libbonoboui. Эти в связке тянут больше чем на мегабайт. С другой стороны,
я вот смотрю на размеры библиотек, входящих в Qt... Мне казалось, они
существенно меньше. А тут, оказывается, одна libQtGui занимает 5 Мб
- больше, чем весь libgtk-x11-2.0. В общем, что-то тут не так, кажется, я в
своё время переоценил тяжесть GNOME.

-- 
  Alexey "Ktirf" Rusakov
  ALT Linux, project manager

Re: [devel] mkimage closure

[Anton Farygin]

Alexey Rusakov пишет:
> (надел противопожарную одежду)
> 
> On Sat, 24 Nov 2007 09:11:47 +0300
> Anton Farygin wrote:
> 
>> Именно.libgnome - просто пример, причём весьма тяжёлый.
> JustTalk, но ради прикола, посмотрите на размер libgnome. Возможно, он вас
> удивит ;)
> Если уж говорить о тяжести GNOME, то это libgnomeui, libbonobo и
> libbonoboui. Эти в связке тянут больше чем на мегабайт. С другой стороны,
> я вот смотрю на размеры библиотек, входящих в Qt... Мне казалось, они
> существенно меньше. А тут, оказывается, одна libQtGui занимает 5 Мб
> - больше, чем весь libgtk-x11-2.0. В общем, что-то тут не так, кажется, я в
> своё время переоценил тяжесть GNOME.
> 

Алексей, под "тяжестью" я имел ввиду не физический объём и даже не объём 
занимаемой памяти, а количество зависимостей. Не более того ;)

Re: [devel] mkimage closure

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

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

On Sat, Nov 24, 2007 at 02:30:06AM +0300, Alexey Rusakov wrote:

AR> Специфическое желание... Здесь нужно довольно-таки фигурно подходить к
AR> выбору запрещаемых пакетов. Иначе есть риск, избегая libgnome, тем не
AR> менее включить в дистрибутив, например, до фига питоновых и перловых
AR> пакетов. Или какую-нибудь тяжёлую игрушку, типа freedroidrpg.
AR> Хотя (только что пришло в голову) в качестве контроля "чистоты" подобное
AR> средство было бы неплохим - например, исключение на *-devel для
AR> не-инструментальных дистрибутивов было бы неплохой идеей.

Но идея разумная. Мне часто хотелось получить, например, "все кроме
требующего иксов". Ибо сервер.

Или "вот этим пакетам я не доверяю принципиально, поэтому их исключить из
сборки для таких-то целей".

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

http://freesource.info
----------------------------------------------------------------------------
Наши кодеры - самые кодерастые кодеры в мире!

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

Re: [devel] mkimage closure

[Alexey Gladkov]

Anton Farygin wrote:
> А есть возможность копировать все пакеты из репозитариев, за исключением 
> списка ?

Сейчас кое-что есть. В git сейчас есть возможность использовать regexp
как включения пакетов, так и для исключения их.

> Т.е. - делать не белый список, а чёрный - только запрещать пакеты из 
> репозитария ?

Я стараюсь.

> Т.е. - когда возникает непреодолимое желание сделать дистрибутив из 
> всего branch/4.0, за исключением ms-ttf-fonts и (что б было интереснее) 
> - libgnome

У меня есть некоторые затруднения с apt, но у меня есть идеи...

-- 
Rgrds, legion

[devel] %gitrelease?

[Michael Shigorin]

On Sat, Nov 24, 2007 at 03:01:21AM +0300, Alexey Gladkov wrote:
> > А есть возможность копировать все пакеты из репозитариев, за
> > исключением списка ?
> Сейчас кое-что есть. В git сейчас есть возможность использовать
> regexp как включения пакетов, так и для исключения их.

Кстати, в git у тебя спек имени 0.0.5-alt2.  Как бы изящно
порешать то, что на самом деле это уже не alt2, но, наверное,
ещё не alt3?

Из того, что наспех пришло в голову -- где-то определять нечто 
вроде "gitYYYYMMDD" (возможно, точнее) и в спеках пакетов,
которые часто доводится после очередной сборки из git
устанавливать с --force для перекрытия формально такой же сборки
-- использовать этот %gitrelease или как там.

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

Re: [devel] %gitrelease?

[Alexey Gladkov]

Michael Shigorin wrote:
> Кстати, в git у тебя спек имени 0.0.5-alt2.  Как бы изящно
> порешать то, что на самом деле это уже не alt2, но, наверное,
> ещё не alt3?

В git сейчас 0.0.6, если не 0.1.0.

> Из того, что наспех пришло в голову -- где-то определять нечто 
> вроде "gitYYYYMMDD" (возможно, точнее) и в спеках пакетов,
> которые часто доводится после очередной сборки из git
> устанавливать с --force для перекрытия формально такой же сборки
> -- использовать этот %gitrelease или как там.

Можно попробовать.

-- 
Rgrds, legion

Re: [devel] mkimage closure

[Anton Farygin]

Alexey Tourbin пишет:
> On Sat, Nov 24, 2007 at 01:11:32AM +0300, Anton Farygin wrote:
>>> 1) Замыкание для мини-дистрибутивов.  Это то что обычно делает apt.
>>> 2) Замыкание для "полноценных дистрбиутивов" -- дополнительно
>>> замыкание по всем подпакетам исходного пакета.
>>>
>>> Второй режим означает, что если напр. вытянулся perl-base,
>>> а исходный пакет у perl-base называется perl-5.8.X-*.src.rpm,
>>> то дополнительно нужно включить все остальные perl-* пакеты,
>>> которые происходят из этого perl-5.8.X-*.src.rpm.
>> А это действительно необходимо ? Хотя скорее всего было бы неплохо 
>> получить такой функционал, но реально он может не понадобиться.
> 
> Этот функционал нужен не "реально", а "идейно".  В полноценный
> дистрибутив нельзя влючать "огрызки", а только "полный набор".
> Тогда как для мини-дистрибутива реальность другая.

В полноценном дистрибутиве я бы предпочёл наблюдать целиком весь branch, 
без огрызков.

Всё остальное можно считать неполноценными дистрибутивами. Ибо помимо 
замыкания по зависимостям и исходным пакетам - нужно замыкание по 
неявным (необъявленным) зависимостям. а это реализовать практически 
нереально не включив весь бранч в дистрибутив.

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

В качестве примера, видимо, можно привести (из последнего) mythtv, 
который явно не зависит от xmltv, lcdproc, mplayer и т.д., но в случае 
наличия их в системе позволяет выполнять дополнительные функции.

> 
>> Мне хотелось бы видеть в mkimage скорее ручку для добавления 
>> конфликтующих пакетов... это сложнее ;)
> 
> Насколько я помню что просматривал git-репозитарий mkimage,
> такая идея у автора была и она в какой-то степени реализована.

Это хорошо, попробую.

Re: [devel] mkimage closure

[Alexey Tourbin]

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

On Sat, Nov 24, 2007 at 02:09:58AM +0300, Anton Farygin wrote:
> > Этот функционал нужен не "реально", а "идейно".  В полноценный
> > дистрибутив нельзя влючать "огрызки", а только "полный набор".
> > Тогда как для мини-дистрибутива реальность другая.
> 
> В полноценном дистрибутиве я бы предпочёл наблюдать целиком весь branch, 
> без огрызков.

Ну... блино!  Ты не математик. :)  Бранч может быть сколь угодно
большим, и весь его тащить нет никакой надобности.  Нужно уметь выделять
"собственные подмножества" это бранча, на которых сохраняются "свойства
структуры" (свойства транзитивного замыкания которые говорят что мы не
выходим за пределы этого контекста).

> Всё остальное можно считать неполноценными дистрибутивами. Ибо помимо 
> замыкания по зависимостям и исходным пакетам - нужно замыкание по 
> неявным (необъявленным) зависимостям. а это реализовать практически 
> нереально не включив весь бранч в дистрибутив.

Да не бывает неявных зависимостей.  Я всё сделал для того чтобы их
не было.  И их более-менее нет.

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

А!  Это дилемма программа vs плагины.  Так можно договориться до того,
что некая расширяемая программа может реализовать некий функционал, но
только в случае наличия в системе осуществляющего этот функционал
пакета.  Или же программа /usr/bin/perl может осуществить некий
функционал РУЛЕЗ, но только в случае наличия в системе дополнительного
пакета с плагином /usr/bin/РУЛЕЗ.

Или же допустим программа /lib/ld-linux.so.2 может реализовать некий
функционал CAT, но только если в системе имееется осуществляющий этот
функционал пакет с файлом /bin/cat.

И вообще кто тебе сказал слово "функционал"?  Забудь.

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

Re: [devel] mkimage closure

[Pavlov Konstantin]

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

On Sat, Nov 24, 2007 at 03:10:04AM +0300, Alexey Tourbin wrote:
> Да не бывает неявных зависимостей.  Я всё сделал для того чтобы их
> не было.  И их более-менее нет.

dlopen?

-- 
Мораль сей басни такова: ломать просто так -- создавать себе
проблемы на ровном месте. :)
		-- mike in sisyphus@

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

Re: [devel] mkimage closure

[Anton Farygin]

Alexey Tourbin пишет:
> On Sat, Nov 24, 2007 at 02:09:58AM +0300, Anton Farygin wrote:
>>> Этот функционал нужен не "реально", а "идейно".  В полноценный
>>> дистрибутив нельзя влючать "огрызки", а только "полный набор".
>>> Тогда как для мини-дистрибутива реальность другая.
>> В полноценном дистрибутиве я бы предпочёл наблюдать целиком весь branch, 
>> без огрызков.
> 
> Ну... блино!  Ты не математик. :)  Бранч может быть сколь угодно
> большим, и весь его тащить нет никакой надобности.  Нужно уметь выделять
> "собственные подмножества" это бранча, на которых сохраняются "свойства
> структуры" (свойства транзитивного замыкания которые говорят что мы не
> выходим за пределы этого контекста).

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

Причина - компилируемый код, в котором вызывается dlopen или fopen.

> 
>> Всё остальное можно считать неполноценными дистрибутивами. Ибо помимо 
>> замыкания по зависимостям и исходным пакетам - нужно замыкание по 
>> неявным (необъявленным) зависимостям. а это реализовать практически 
>> нереально не включив весь бранч в дистрибутив.
> 
> Да не бывает неявных зависимостей.  Я всё сделал для того чтобы их
> не было.  И их более-менее нет.

К сожалению в случае с компилируемым кодом - это не так.

> 
>> Речь идёт о пакетах, которые могли бы реализовать некий функционал, но 
>> только в случае наличия в системе осуществляющих этот функционал 
>> дополнительных пакетов.
> 
> А!  Это дилемма программа vs плагины.  Так можно договориться до того,
> что некая расширяемая программа может реализовать некий функционал, но
> только в случае наличия в системе осуществляющего этот функционал
> пакета.  Или же программа /usr/bin/perl может осуществить некий
> функционал РУЛЕЗ, но только в случае наличия в системе дополнительного
> пакета с плагином /usr/bin/РУЛЕЗ.

Да, о том и речь.

> 
> Или же допустим программа /lib/ld-linux.so.2 может реализовать некий
> функционал CAT, но только если в системе имееется осуществляющий этот
> функционал пакет с файлом /bin/cat.

Нет, это перебор.

> 
> И вообще кто тебе сказал слово "функционал"?  Забудь.

В этом случае можно забыть о корректном замыкании. Не знаю, кто - как, 
но я ещё нарываюсь на пакеты, которые не запускаются без установки 
/usr/lib/рулез.so.x

Re: [devel] mkimage closure

[Alexey Tourbin]

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

On Sat, Nov 24, 2007 at 09:16:39AM +0300, Anton Farygin wrote:
> > И вообще кто тебе сказал слово "функционал"?  Забудь.
> В этом случае можно забыть о корректном замыкании. Не знаю, кто - как, 

Я наверное по пьяни хотел пошутить что функционал это такое слово
со специфическим значением из области to whom it may concern.
http://ru.wikipedia.org/wiki/Функционал

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

Re: [devel] mkimage closure

[Хихин Руслан]

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

Здравствуйте Alexey Tourbin
  В сообщении от 24 ноября 2007 Alexey Tourbin написал(a):
 > Да не бывает неявных зависимостей.  Я всё сделал для того чтобы их
 > не было.  И их более-менее нет.
Алексей - что-бы вы не делали неявные зависимости будут всегда. Хотя-бы 
всилу того, что язык описания зависимостей в RPM неполноценен - не 
учтиывает зависимости типа ИЛИ и Двоичного ИЛИ.
Хотя большое спасибо, за то, что вы делаете.

-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] mkimage closure

[Aleksey Novodvorsky]

On 11/24/07, Anton Farygin <rider@altlinux.com> wrote:
> Alexey Tourbin пишет:
> > On Sat, Nov 24, 2007 at 01:11:32AM +0300, Anton Farygin wrote:
> >>> 1) Замыкание для мини-дистрибутивов.  Это то что обычно делает apt.
> >>> 2) Замыкание для "полноценных дистрбиутивов" -- дополнительно
> >>> замыкание по всем подпакетам исходного пакета.
> >>>
> >>> Второй режим означает, что если напр. вытянулся perl-base,
> >>> а исходный пакет у perl-base называется perl-5.8.X-*.src.rpm,
> >>> то дополнительно нужно включить все остальные perl-* пакеты,
> >>> которые происходят из этого perl-5.8.X-*.src.rpm.
> >> А это действительно необходимо ? Хотя скорее всего было бы неплохо
> >> получить такой функционал, но реально он может не понадобиться.
> >
> > Этот функционал нужен не "реально", а "идейно".  В полноценный
> > дистрибутив нельзя влючать "огрызки", а только "полный набор".
> > Тогда как для мини-дистрибутива реальность другая.
>
> В полноценном дистрибутиве я бы предпочёл наблюдать целиком весь branch,
> без огрызков.

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


Rgrds, Алексей

>
> Всё остальное можно считать неполноценными дистрибутивами. Ибо помимо
> замыкания по зависимостям и исходным пакетам - нужно замыкание по
> неявным (необъявленным) зависимостям. а это реализовать практически
> нереально не включив весь бранч в дистрибутив.
>
> Речь идёт о пакетах, которые могли бы реализовать некий функционал, но
> только в случае наличия в системе осуществляющих этот функционал
> дополнительных пакетов.
>
> В качестве примера, видимо, можно привести (из последнего) mythtv,
> который явно не зависит от xmltv, lcdproc, mplayer и т.д., но в случае
> наличия их в системе позволяет выполнять дополнительные функции.
>
> >
> >> Мне хотелось бы видеть в mkimage скорее ручку для добавления
> >> конфликтующих пакетов... это сложнее ;)
> >
> > Насколько я помню что просматривал git-репозитарий mkimage,
> > такая идея у автора была и она в какой-то степени реализована.
>
> Это хорошо, попробую.
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] mkimage closure

[Anton Farygin]

Aleksey Novodvorsky пишет:
> On 11/24/07, Anton Farygin <rider@altlinux.com> wrote:
>> Alexey Tourbin пишет:
>>> On Sat, Nov 24, 2007 at 01:11:32AM +0300, Anton Farygin wrote:
>>>>> 1) Замыкание для мини-дистрибутивов.  Это то что обычно делает apt.
>>>>> 2) Замыкание для "полноценных дистрбиутивов" -- дополнительно
>>>>> замыкание по всем подпакетам исходного пакета.
>>>>>
>>>>> Второй режим означает, что если напр. вытянулся perl-base,
>>>>> а исходный пакет у perl-base называется perl-5.8.X-*.src.rpm,
>>>>> то дополнительно нужно включить все остальные perl-* пакеты,
>>>>> которые происходят из этого perl-5.8.X-*.src.rpm.
>>>> А это действительно необходимо ? Хотя скорее всего было бы неплохо
>>>> получить такой функционал, но реально он может не понадобиться.
>>> Этот функционал нужен не "реально", а "идейно".  В полноценный
>>> дистрибутив нельзя влючать "огрызки", а только "полный набор".
>>> Тогда как для мини-дистрибутива реальность другая.
>> В полноценном дистрибутиве я бы предпочёл наблюдать целиком весь branch,
>> без огрызков.
> 
> Зачем такой дистрибутив,  когда есть бранч?  То есть я понимаю, что
> есть юзеры, которые привыкли к такому, потому его надо выпустить. Но
> вот зачем он по сути -- не знаю.
> Но.
> Мне представляется абсолютно необходимым для каждого нашего
> дистрибутива строить и выкладывать его замыкание по сборке.

Замыкание по сборке - безусловно хорошо и нужно.

Я веду речь о замыкании по функционалу.

Давайте ещё раз посмотрим действия человека, который добавляет 
(например) пакет mythtv в дистрибутив. Если прописать только mythtv в 
список необходимых пакетов, то будет работать примерно 20% его функционала.

Я могу добавить в него зависимости, но в этом случае сложно будет 
собрать систему, в которой _должно_ работать 20% функционала mythtv.

Надеюсь, ты понимаешь о чём я говорю.

Re: [devel] mkimage closure

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

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

On Sat, Nov 24, 2007 at 03:14:18AM +0300, Aleksey Novodvorsky wrote:

AN> Зачем такой дистрибутив,  когда есть бранч?  То есть я понимаю, что
AN> есть юзеры, которые привыкли к такому, потому его надо выпустить. Но
AN> вот зачем он по сути -- не знаю.
AN> Но.
AN> Мне представляется абсолютно необходимым для каждого нашего
AN> дистрибутива строить и выкладывать его замыкание по сборке.

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

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

http://freesource.info
----------------------------------------------------------------------------
PHP5 - жизнь не может быть скучной.
		-- legion in devel@

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

Re: [devel] mkimage closure

[Alexey Rusakov]

On Sat, 24 Nov 2007 02:09:58 +0300
Anton Farygin wrote:


> Alexey Tourbin пишет:
> > On Sat, Nov 24, 2007 at 01:11:32AM +0300, Anton Farygin wrote:
> >>> 1) Замыкание для мини-дистрибутивов.  Это то что обычно делает apt.
> >>> 2) Замыкание для "полноценных дистрбиутивов" -- дополнительно
> >>> замыкание по всем подпакетам исходного пакета.
> >>>
> >>> Второй режим означает, что если напр. вытянулся perl-base,
> >>> а исходный пакет у perl-base называется perl-5.8.X-*.src.rpm,
> >>> то дополнительно нужно включить все остальные perl-* пакеты,
> >>> которые происходят из этого perl-5.8.X-*.src.rpm.
> >> А это действительно необходимо ? Хотя скорее всего было бы неплохо 
> >> получить такой функционал, но реально он может не понадобиться.
> > 
> > Этот функционал нужен не "реально", а "идейно".  В полноценный
> > дистрибутив нельзя влючать "огрызки", а только "полный набор".
> > Тогда как для мини-дистрибутива реальность другая.
> 
> В полноценном дистрибутиве я бы предпочёл наблюдать целиком весь branch, 
> без огрызков.
А я бы предпочёл не делать из дистрибутива снимок бранча. Даже в случае
Мастера это не слишком оправдано. Диск с контрибами - да, но дистрибутив
должен быть законченным продуктом без лишних пакетов. Даже такой пухлый
как Мастер. ИМХО.

> Всё остальное можно считать неполноценными дистрибутивами. Ибо помимо 
> замыкания по зависимостям и исходным пакетам - нужно замыкание по 
> неявным (необъявленным) зависимостям. а это реализовать практически 
> нереально не включив весь бранч в дистрибутив.
Вполне реально, если этим озаботиться. Да, работы много. Зато дистрибутив
не будет свалкой пакетов с приделанными к ней инсталлятором и дизайном.

-- 
  Alexey "Ktirf" Rusakov
  ALT Linux, project manager

Re: [devel] mkimage closure

[Anton Farygin]

Alexey Rusakov пишет:
> On Sat, 24 Nov 2007 02:09:58 +0300
> Anton Farygin wrote:
> 
> 
>> Alexey Tourbin пишет:
>>> On Sat, Nov 24, 2007 at 01:11:32AM +0300, Anton Farygin wrote:
>>>>> 1) Замыкание для мини-дистрибутивов.  Это то что обычно делает apt.
>>>>> 2) Замыкание для "полноценных дистрбиутивов" -- дополнительно
>>>>> замыкание по всем подпакетам исходного пакета.
>>>>>
>>>>> Второй режим означает, что если напр. вытянулся perl-base,
>>>>> а исходный пакет у perl-base называется perl-5.8.X-*.src.rpm,
>>>>> то дополнительно нужно включить все остальные perl-* пакеты,
>>>>> которые происходят из этого perl-5.8.X-*.src.rpm.
>>>> А это действительно необходимо ? Хотя скорее всего было бы неплохо 
>>>> получить такой функционал, но реально он может не понадобиться.
>>> Этот функционал нужен не "реально", а "идейно".  В полноценный
>>> дистрибутив нельзя влючать "огрызки", а только "полный набор".
>>> Тогда как для мини-дистрибутива реальность другая.
>> В полноценном дистрибутиве я бы предпочёл наблюдать целиком весь branch, 
>> без огрызков.
> А я бы предпочёл не делать из дистрибутива снимок бранча. Даже в случае
> Мастера это не слишком оправдано. Диск с контрибами - да, но дистрибутив
> должен быть законченным продуктом без лишних пакетов. Даже такой пухлый
> как Мастер. ИМХО.

В случае с Master'ом - это более оправданно, чем в случае с любым другим 
дистрибутивом.

Никакой человек не сможет в разумное время переработать 6-7 тысяч 
пакетов и составить корректные списки для их установки.

> 
>> Всё остальное можно считать неполноценными дистрибутивами. Ибо помимо 
>> замыкания по зависимостям и исходным пакетам - нужно замыкание по 
>> неявным (необъявленным) зависимостям. а это реализовать практически 
>> нереально не включив весь бранч в дистрибутив.
> Вполне реально, если этим озаботиться. Да, работы много. Зато дистрибутив
> не будет свалкой пакетов с приделанными к ней инсталлятором и дизайном.

Дистрибутив типа "Мастер" всегда будет оставаться свалкой пакетов, хотим 
мы этого или нет.

Если из него исключить большое количество имеющихся в Sisyphus пакетов - 
то это будет уже на Master, а как раз Desctop + Contrib. И смысл в 
выпуске Master'а станет исчезающе мал.

Re: [devel] mkimage closure

[Alexey Rusakov]

On Sat, 24 Nov 2007 09:22:27 +0300
Anton Farygin wrote:

> Alexey Rusakov пишет:
> > On Sat, 24 Nov 2007 02:09:58 +0300
> > Anton Farygin wrote:
> > 
> > 
> >> Alexey Tourbin пишет:
> >>> On Sat, Nov 24, 2007 at 01:11:32AM +0300, Anton Farygin wrote:
> >>>>> 1) Замыкание для мини-дистрибутивов.  Это то что обычно делает apt.
> >>>>> 2) Замыкание для "полноценных дистрбиутивов" -- дополнительно
> >>>>> замыкание по всем подпакетам исходного пакета.
> >>>>>
> >>>>> Второй режим означает, что если напр. вытянулся perl-base,
> >>>>> а исходный пакет у perl-base называется perl-5.8.X-*.src.rpm,
> >>>>> то дополнительно нужно включить все остальные perl-* пакеты,
> >>>>> которые происходят из этого perl-5.8.X-*.src.rpm.
> >>>> А это действительно необходимо ? Хотя скорее всего было бы неплохо 
> >>>> получить такой функционал, но реально он может не понадобиться.
> >>> Этот функционал нужен не "реально", а "идейно".  В полноценный
> >>> дистрибутив нельзя влючать "огрызки", а только "полный набор".
> >>> Тогда как для мини-дистрибутива реальность другая.
> >> В полноценном дистрибутиве я бы предпочёл наблюдать целиком весь branch, 
> >> без огрызков.
> > А я бы предпочёл не делать из дистрибутива снимок бранча. Даже в случае
> > Мастера это не слишком оправдано. Диск с контрибами - да, но дистрибутив
> > должен быть законченным продуктом без лишних пакетов. Даже такой пухлый
> > как Мастер. ИМХО.
> 
> В случае с Master'ом - это более оправданно, чем в случае с любым другим 
> дистрибутивом.
> 
> Никакой человек не сможет в разумное время переработать 6-7 тысяч 
> пакетов и составить корректные списки для их установки.
Уф... Да потому что не надо перерабатывать 6-7 тысяч пакетов. Это
неправильная посылка. Посылка должна быть вот именно что от функционала.

> >> Всё остальное можно считать неполноценными дистрибутивами. Ибо помимо 
> >> замыкания по зависимостям и исходным пакетам - нужно замыкание по 
> >> неявным (необъявленным) зависимостям. а это реализовать практически 
> >> нереально не включив весь бранч в дистрибутив.
> > Вполне реально, если этим озаботиться. Да, работы много. Зато дистрибутив
> > не будет свалкой пакетов с приделанными к ней инсталлятором и дизайном.
> 
> Дистрибутив типа "Мастер" всегда будет оставаться свалкой пакетов, хотим 
> мы этого или нет.
Я против. И буду прикладывать усилия к тому, чтобы Мастер стал нормальным
инструментальным дистрибутивом.

> Если из него исключить большое количество имеющихся в Sisyphus пакетов - 
> то это будет уже на Master, а как раз Desctop + Contrib. И смысл в 
> выпуске Master'а станет исчезающе мал.
Как же вы не понимаете... Desktop + Contrib - это как раз и есть
фактически срез бранча (в части Contrib). И я не хочу, чтобы Мастер был
таким же срезом, только Contrib формально вошёл в состав дистрибутива.
Нужна нормальная категоризация пакетов (для всего Мастера), нужна
возможность выбора той конфигурации установки, которая нужна пользователю.
И за рамками объединения этих конфигураций должно остаться не так уж много
пакетов. И я бы очень хотел, чтобы у Мастера тоже был свой Contrib,
который вот именно что "всё остальное", свалка. Но чтобы в дистрибутив она
входила исключительно как Contrib.

Просто вот эту самую черту между устанавливаемым комплектом и "всем
остальным" - нужно проводить. И ради математической стройности, которую
любит at@, и ради удобства пользователя, и ради позиционирования, в конце
концов.

-- 
  Alexey "Ktirf" Rusakov
  ALT Linux, project manager

Re: [devel] mkimage closure

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

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

On Sat, Nov 24, 2007 at 11:01:02AM +0300, Alexey Rusakov wrote:

>> Дистрибутив типа "Мастер" всегда будет оставаться свалкой пакетов, хотим 
>> мы этого или нет.
AR> Я против. И буду прикладывать усилия к тому, чтобы Мастер стал нормальным
AR> инструментальным дистрибутивом.

Это не взаимоисключающие понятия в случае Мастера :)

Основное назначение мастера, IMHO, чтобы каждый там нашел то, что _ему_
нужно. Сам он при этом не специализирован.

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

http://freesource.info
----------------------------------------------------------------------------
Просьба не путать incominger@ и incominger. :)
		-- ldv in devel@

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

Re: [devel] mkimage closure

[Anton Farygin]

Денис Смирнов пишет:
> On Sat, Nov 24, 2007 at 11:01:02AM +0300, Alexey Rusakov wrote:
> 
>>> Дистрибутив типа "Мастер" всегда будет оставаться свалкой пакетов, хотим 
>>> мы этого или нет.
> AR> Я против. И буду прикладывать усилия к тому, чтобы Мастер стал нормальным
> AR> инструментальным дистрибутивом.
> 
> Это не взаимоисключающие понятия в случае Мастера :)
> 
> Основное назначение мастера, IMHO, чтобы каждый там нашел то, что _ему_
> нужно. Сам он при этом не специализирован.

+1

Re: [devel] mkimage closure

[Anton Farygin]

Alexey Rusakov пишет:
> On Sat, 24 Nov 2007 09:22:27 +0300
> Anton Farygin wrote:
> 
>> Alexey Rusakov пишет:
>>> On Sat, 24 Nov 2007 02:09:58 +0300
>>> Anton Farygin wrote:
>>>
>>>
>>>> Alexey Tourbin пишет:
>>>>> On Sat, Nov 24, 2007 at 01:11:32AM +0300, Anton Farygin wrote:
>>>>>>> 1) Замыкание для мини-дистрибутивов.  Это то что обычно делает apt.
>>>>>>> 2) Замыкание для "полноценных дистрбиутивов" -- дополнительно
>>>>>>> замыкание по всем подпакетам исходного пакета.
>>>>>>>
>>>>>>> Второй режим означает, что если напр. вытянулся perl-base,
>>>>>>> а исходный пакет у perl-base называется perl-5.8.X-*.src.rpm,
>>>>>>> то дополнительно нужно включить все остальные perl-* пакеты,
>>>>>>> которые происходят из этого perl-5.8.X-*.src.rpm.
>>>>>> А это действительно необходимо ? Хотя скорее всего было бы неплохо 
>>>>>> получить такой функционал, но реально он может не понадобиться.
>>>>> Этот функционал нужен не "реально", а "идейно".  В полноценный
>>>>> дистрибутив нельзя влючать "огрызки", а только "полный набор".
>>>>> Тогда как для мини-дистрибутива реальность другая.
>>>> В полноценном дистрибутиве я бы предпочёл наблюдать целиком весь branch, 
>>>> без огрызков.
>>> А я бы предпочёл не делать из дистрибутива снимок бранча. Даже в случае
>>> Мастера это не слишком оправдано. Диск с контрибами - да, но дистрибутив
>>> должен быть законченным продуктом без лишних пакетов. Даже такой пухлый
>>> как Мастер. ИМХО.
>> В случае с Master'ом - это более оправданно, чем в случае с любым другим 
>> дистрибутивом.
>>
>> Никакой человек не сможет в разумное время переработать 6-7 тысяч 
>> пакетов и составить корректные списки для их установки.
> Уф... Да потому что не надо перерабатывать 6-7 тысяч пакетов. Это
> неправильная посылка. Посылка должна быть вот именно что от функционала.

Как быть, если функциональное назначение решения требует наличия на 
диске всех пакетов ?

> 
>>>> Всё остальное можно считать неполноценными дистрибутивами. Ибо помимо 
>>>> замыкания по зависимостям и исходным пакетам - нужно замыкание по 
>>>> неявным (необъявленным) зависимостям. а это реализовать практически 
>>>> нереально не включив весь бранч в дистрибутив.
>>> Вполне реально, если этим озаботиться. Да, работы много. Зато дистрибутив
>>> не будет свалкой пакетов с приделанными к ней инсталлятором и дизайном.
>> Дистрибутив типа "Мастер" всегда будет оставаться свалкой пакетов, хотим 
>> мы этого или нет.
> Я против. И буду прикладывать усилия к тому, чтобы Мастер стал нормальным
> инструментальным дистрибутивом.

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

Могут оказаться ценными даже исходные тексты warzone2100 ;)

> 
>> Если из него исключить большое количество имеющихся в Sisyphus пакетов - 
>> то это будет уже на Master, а как раз Desctop + Contrib. И смысл в 
>> выпуске Master'а станет исчезающе мал.
> Как же вы не понимаете... Desktop + Contrib - это как раз и есть
> фактически срез бранча (в части Contrib). И я не хочу, чтобы Мастер был
> таким же срезом, только Contrib формально вошёл в состав дистрибутива.
> Нужна нормальная категоризация пакетов (для всего Мастера), нужна
> возможность выбора той конфигурации установки, которая нужна пользователю.
> И за рамками объединения этих конфигураций должно остаться не так уж много
> пакетов. И я бы очень хотел, чтобы у Мастера тоже был свой Contrib,
> который вот именно что "всё остальное", свалка. Но чтобы в дистрибутив она
> входила исключительно как Contrib.

В идеале - как раз полное отсутствие контриба. Но для этого нужно 
перепахать весь branch/4.0

> 
> Просто вот эту самую черту между устанавливаемым комплектом и "всем
> остальным" - нужно проводить. И ради математической стройности, которую
> любит at@, и ради удобства пользователя, и ради позиционирования, в конце
> концов.

Безусловно, но при этом нужно здраво оценивать свои силы.

Re: [devel] mkimage closure

[Aleksey Novodvorsky]

On 11/25/07, Anton Farygin <rider@altlinux.com> wrote:
> Alexey Rusakov пишет:
> > On Sat, 24 Nov 2007 09:22:27 +0300
> > Anton Farygin wrote:
> >
> >> Alexey Rusakov пишет:
> >>> On Sat, 24 Nov 2007 02:09:58 +0300
> >>> Anton Farygin wrote:
> >>>
> >>>
> >>>> Alexey Tourbin пишет:
> >>>>> On Sat, Nov 24, 2007 at 01:11:32AM +0300, Anton Farygin wrote:
> >>>>>>> 1) Замыкание для мини-дистрибутивов.  Это то что обычно делает apt.
> >>>>>>> 2) Замыкание для "полноценных дистрбиутивов" -- дополнительно
> >>>>>>> замыкание по всем подпакетам исходного пакета.
> >>>>>>>
> >>>>>>> Второй режим означает, что если напр. вытянулся perl-base,
> >>>>>>> а исходный пакет у perl-base называется perl-5.8.X-*.src.rpm,
> >>>>>>> то дополнительно нужно включить все остальные perl-* пакеты,
> >>>>>>> которые происходят из этого perl-5.8.X-*.src.rpm.
> >>>>>> А это действительно необходимо ? Хотя скорее всего было бы неплохо
> >>>>>> получить такой функционал, но реально он может не понадобиться.
> >>>>> Этот функционал нужен не "реально", а "идейно".  В полноценный
> >>>>> дистрибутив нельзя влючать "огрызки", а только "полный набор".
> >>>>> Тогда как для мини-дистрибутива реальность другая.
> >>>> В полноценном дистрибутиве я бы предпочёл наблюдать целиком весь branch,
> >>>> без огрызков.
> >>> А я бы предпочёл не делать из дистрибутива снимок бранча. Даже в случае
> >>> Мастера это не слишком оправдано. Диск с контрибами - да, но дистрибутив
> >>> должен быть законченным продуктом без лишних пакетов. Даже такой пухлый
> >>> как Мастер. ИМХО.
> >> В случае с Master'ом - это более оправданно, чем в случае с любым другим
> >> дистрибутивом.
> >>
> >> Никакой человек не сможет в разумное время переработать 6-7 тысяч
> >> пакетов и составить корректные списки для их установки.
> > Уф... Да потому что не надо перерабатывать 6-7 тысяч пакетов. Это
> > неправильная посылка. Посылка должна быть вот именно что от функционала.
>
> Как быть, если функциональное назначение решения требует наличия на
> диске всех пакетов ?
>
> >
> >>>> Всё остальное можно считать неполноценными дистрибутивами. Ибо помимо
> >>>> замыкания по зависимостям и исходным пакетам - нужно замыкание по
> >>>> неявным (необъявленным) зависимостям. а это реализовать практически
> >>>> нереально не включив весь бранч в дистрибутив.
> >>> Вполне реально, если этим озаботиться. Да, работы много. Зато дистрибутив
> >>> не будет свалкой пакетов с приделанными к ней инсталлятором и дизайном.
> >> Дистрибутив типа "Мастер" всегда будет оставаться свалкой пакетов, хотим
> >> мы этого или нет.
> > Я против. И буду прикладывать усилия к тому, чтобы Мастер стал нормальным
> > инструментальным дистрибутивом.
>
> Мастер не может стать нормальным инструментальным дистрибутивом, без
> наличия в нём всей пакетной базы.
>
> Могут оказаться ценными даже исходные тексты warzone2100 ;)
>
> >
> >> Если из него исключить большое количество имеющихся в Sisyphus пакетов -
> >> то это будет уже на Master, а как раз Desctop + Contrib. И смысл в
> >> выпуске Master'а станет исчезающе мал.
> > Как же вы не понимаете... Desktop + Contrib - это как раз и есть
> > фактически срез бранча (в части Contrib). И я не хочу, чтобы Мастер был
> > таким же срезом, только Contrib формально вошёл в состав дистрибутива.
> > Нужна нормальная категоризация пакетов (для всего Мастера), нужна
> > возможность выбора той конфигурации установки, которая нужна пользователю.
> > И за рамками объединения этих конфигураций должно остаться не так уж много
> > пакетов. И я бы очень хотел, чтобы у Мастера тоже был свой Contrib,
> > который вот именно что "всё остальное", свалка. Но чтобы в дистрибутив она
> > входила исключительно как Contrib.
>
> В идеале - как раз полное отсутствие контриба. Но для этого нужно
> перепахать весь branch/4.0

Нет, так мы его не выустим. Я вижу Master как инструментальный
дистрибутив, то есть в нем надо "перепахать" средства разработки в
дополнение к тому, что входит в Server и Desktop. И, естественно, он
должен быть замкнут по сборке.
Остальное -- contrib.
Rgrds, Алекесй

>
> >
> > Просто вот эту самую черту между устанавливаемым комплектом и "всем
> > остальным" - нужно проводить. И ради математической стройности, которую
> > любит at@, и ради удобства пользователя, и ради позиционирования, в конце
> > концов.
>
> Безусловно, но при этом нужно здраво оценивать свои силы.
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] mkimage closure

[Michael Shigorin]

On Sun, Nov 25, 2007 at 04:16:53AM +0300, Aleksey Novodvorsky wrote:
> Нет, так мы его не выустим. Я вижу Master как инструментальный
> дистрибутив, то есть в нем надо "перепахать" средства
> разработки в дополнение к тому, что входит в Server и Desktop.

Я бы ещё заикнулся про документацию по alterator...

> Остальное -- contrib.

Угу.

"Без контриба" на самом деле грустней, чем "с контрибом".
Слишком высокая планка для разумного ненапряжного участия.

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

Re: [devel] mkimage closure

[Michael Shigorin]

On Sat, Nov 24, 2007 at 09:22:27AM +0300, Anton Farygin wrote:
> Дистрибутив типа "Мастер" всегда будет оставаться свалкой
> пакетов, хотим мы этого или нет.

Мне кажется, возможен довольно изящный вариант обхода:
основной диск, содержащий _разумный_ набор как для десктопа
(KDE/GNOME/XFCE/IceWM/WindowMaker/*box), так и для сервера.
И хорошо бы thin basesystem, как вот минимальный Master обычно 
умел метров в двести встать.

Набор сделать не особо сложно, поскольку списки или уже есть 
в профилях server/desktop/lite, или есть люди, которые
заинтересованы их составить.

Если при этом получится к Master (как понимаю, уже 4.1) разумным
образом обрулить в инсталере этот выбор (поскольку и схема
разбивки меняется, и дефолты по пакетам, и возможно -- состав
stage3) -- мне кажется, может получиться "не хуже ALM2.4", 
который многие вспоминают тёплым словом за удачный состав
и работоспособность.

А всё остальное -- в contrib.

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

Re: [devel] mkimage closure

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

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

On Sat, Nov 24, 2007 at 12:02:36PM +0200, Michael Shigorin wrote:

>> Дистрибутив типа "Мастер" всегда будет оставаться свалкой
>> пакетов, хотим мы этого или нет.
MS> Мне кажется, возможен довольно изящный вариант обхода:
MS> основной диск, содержащий _разумный_ набор как для десктопа
MS> (KDE/GNOME/XFCE/IceWM/WindowMaker/*box), так и для сервера.
MS> И хорошо бы thin basesystem, как вот минимальный Master обычно 
MS> умел метров в двести встать.

[skip]

+1

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

http://freesource.info
----------------------------------------------------------------------------
Но если нельзя будет отключить русский перевод, я напьюсь водки.
		-- at in devel@

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

Re: [devel] mkimage closure

[Alexey Rusakov]

On Sat, 24 Nov 2007 12:02:36 +0200
Michael Shigorin wrote:


> On Sat, Nov 24, 2007 at 09:22:27AM +0300, Anton Farygin wrote:
> > Дистрибутив типа "Мастер" всегда будет оставаться свалкой
> > пакетов, хотим мы этого или нет.
> 
> Мне кажется, возможен довольно изящный вариант обхода:
> основной диск, содержащий _разумный_ набор как для десктопа
> (KDE/GNOME/XFCE/IceWM/WindowMaker/*box), так и для сервера.
> И хорошо бы thin basesystem, как вот минимальный Master обычно 
> умел метров в двести встать.
> 
> Набор сделать не особо сложно, поскольку списки или уже есть 
> в профилях server/desktop/lite, или есть люди, которые
> заинтересованы их составить.
> 
> Если при этом получится к Master (как понимаю, уже 4.1) разумным
> образом обрулить в инсталере этот выбор (поскольку и схема
> разбивки меняется, и дефолты по пакетам, и возможно -- состав
> stage3) -- мне кажется, может получиться "не хуже ALM2.4", 
> который многие вспоминают тёплым словом за удачный состав
> и работоспособность.
> 
> А всё остальное -- в contrib.
Вот у меня такая примерно картинка в голове и есть относительно Мастера.
Осталось найти релиз-менеджера... :)

-- 
  Alexey "Ktirf" Rusakov
  ALT Linux, project manager

Re: [devel] mkimage closure

[Anton Farygin]

Alexey Rusakov пишет:
> On Sat, 24 Nov 2007 12:02:36 +0200
> Michael Shigorin wrote:
> 
> 
>> On Sat, Nov 24, 2007 at 09:22:27AM +0300, Anton Farygin wrote:
>>> Дистрибутив типа "Мастер" всегда будет оставаться свалкой
>>> пакетов, хотим мы этого или нет.
>> Мне кажется, возможен довольно изящный вариант обхода:
>> основной диск, содержащий _разумный_ набор как для десктопа
>> (KDE/GNOME/XFCE/IceWM/WindowMaker/*box), так и для сервера.
>> И хорошо бы thin basesystem, как вот минимальный Master обычно 
>> умел метров в двести встать.
>>
>> Набор сделать не особо сложно, поскольку списки или уже есть 
>> в профилях server/desktop/lite, или есть люди, которые
>> заинтересованы их составить.
>>
>> Если при этом получится к Master (как понимаю, уже 4.1) разумным
>> образом обрулить в инсталере этот выбор (поскольку и схема
>> разбивки меняется, и дефолты по пакетам, и возможно -- состав
>> stage3) -- мне кажется, может получиться "не хуже ALM2.4", 
>> который многие вспоминают тёплым словом за удачный состав
>> и работоспособность.
>>
>> А всё остальное -- в contrib.
> Вот у меня такая примерно картинка в голове и есть относительно Мастера.
> Осталось найти релиз-менеджера... :)
> 

Алексей, инциатива наказуема.. возьмётесь ? ;)

Не в ушерб остальному, плз ;)

Наверное у нас в офисе остался всего один разработчик, который никогда 
не выпускал дистрибутивы в качестве релиз-менеджера ;)

Re: [devel] mkimage closure

[Michael Shigorin]

On Sun, Nov 25, 2007 at 01:12:09AM +0300, Alexey Rusakov wrote:
> Вот у меня такая примерно картинка в голове и есть относительно Мастера.
> Осталось найти релиз-менеджера... :)

Ну найдись :)

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

Re: [devel] mkimage closure

[Alexey Rusakov]

On Sun, 25 Nov 2007 21:49:32 +0200
Michael Shigorin wrote:


> On Sun, Nov 25, 2007 at 01:12:09AM +0300, Alexey Rusakov wrote:
> > Вот у меня такая примерно картинка в голове и есть относительно Мастера.
> > Осталось найти релиз-менеджера... :)
> 
> Ну найдись :)
Вот же противные, а?.. И что мне за это будет? :)

-- 
  Alexey "Ktirf" Rusakov
  ALT Linux, project manager

Re: [devel] mkimage closure

[Anton Farygin]

Alexey Rusakov пишет:
> On Sun, 25 Nov 2007 21:49:32 +0200
> Michael Shigorin wrote:
> 
> 
>> On Sun, Nov 25, 2007 at 01:12:09AM +0300, Alexey Rusakov wrote:
>>> Вот у меня такая примерно картинка в голове и есть относительно Мастера.
>>> Осталось найти релиз-менеджера... :)
>> Ну найдись :)
> Вот же противные, а?.. И что мне за это будет? :)
> 

За это тебя на фесте сильно никто не утопит ;) Правда зависит от того, 
что получится на выходе.

Re: [devel] mkimage closure

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

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

On Mon, Nov 26, 2007 at 11:08:20AM +0300, Anton Farygin wrote:

>>>> Вот у меня такая примерно картинка в голове и есть относительно Мастера.
>>>> Осталось найти релиз-менеджера... :)
>>> Ну найдись :)
>> Вот же противные, а?.. И что мне за это будет? :)
AF> За это тебя на фесте сильно никто не утопит ;) Правда зависит от того, 
AF> что получится на выходе.

С учетом сложности задачи у меня есть подозрение что взявшийся за эту
работу утоплен будет однозначно :)

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

http://freesource.info
----------------------------------------------------------------------------
Новый компьютер сломается как раз тогда, когда старый отключат и выбросят.

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

Re: [devel] mkimage closure

[Anton Farygin]

Денис Смирнов пишет:
> On Mon, Nov 26, 2007 at 11:08:20AM +0300, Anton Farygin wrote:
> 
>>>>> Вот у меня такая примерно картинка в голове и есть относительно Мастера.
>>>>> Осталось найти релиз-менеджера... :)
>>>> Ну найдись :)
>>> Вот же противные, а?.. И что мне за это будет? :)
> AF> За это тебя на фесте сильно никто не утопит ;) Правда зависит от того, 
> AF> что получится на выходе.
> 
> С учетом сложности задачи у меня есть подозрение что взявшийся за эту
> работу утоплен будет однозначно :)

Т.е. - результат будет всегда ожидаемо плохим ?

Re: [devel] mkimage closure

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

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

On Mon, Nov 26, 2007 at 12:01:38PM +0300, Anton Farygin wrote:

>> С учетом сложности задачи у меня есть подозрение что взявшийся за эту
>> работу утоплен будет однозначно :)
AF> Т.е. - результат будет всегда ожидаемо плохим ?

То есть к результат будет хотя бы для кого-нибудь ожидаемо плохим.

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

За подобную работу я бы брался только при гарантии личной охраны на фесте
:)

Хотя все не так страшно, ибо выпускается он уже после всех остальных
дистрибутивов серии, когда основные шишки уже набиты другими
релиз-менеджерами.

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

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

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

http://freesource.info
----------------------------------------------------------------------------
> 2. нельзя объять необъятное;
Это точно :-). Можно сломать необъятное :-).
		-- morozov in sisyphus@

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

[devel] ALM4.1

[Michael Shigorin]

On Mon, Nov 26, 2007 at 01:11:21AM +0300, Alexey Rusakov wrote:
> > > Вот у меня такая примерно картинка в голове и есть
> > > относительно Мастера.  Осталось найти релиз-менеджера... :)
> > Ну найдись :)
> Вот же противные, а?.. И что мне за это будет? :)

Как обычно, благодарность коллег и ощущение, что иначе могло быть 
и хуже. :)

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

Re: [devel] mkimage closure

[Alexey Gladkov]

Anton Farygin wrote:
> А это действительно необходимо ? Хотя скорее всего было бы неплохо 
> получить такой функционал, но реально он может не понадобиться.
> 
> Мне хотелось бы видеть в mkimage скорее ручку для добавления 
> конфликтующих пакетов... это сложнее ;)

Как я уже сказал, в mkimage  есть такая возможность. Может её стоит
реализовать лучше.

-- 
Rgrds, legion