[devel] Q: cvs inquiry

[devel] Q: cvs inquiry

[Dmitry V. Levin]

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

Greetings!

У меня есть небольшой опрос по некоторым аспектам функционирования CVS
package repository.

1. Уведомления о внесении изменений в CVS (o commit'ах).
  Как следует это организовать, чтобы каждый получал только ту информацию,
  которая его интересует. Эта система должна быть приспособлена (и даже
  ориентирована) к появлению новых пакетов.

2. Сборка исходных и готовых к установке пакетов.
  Когда это следует делать? Если при commit'е, то при каком именно (при
  commit'е каких именно файлов)? Если при rtag'е (пока cvs это не умеет),
  то опять же, когда именно?
  Следует иметь в виду тот факт, что сборка происходит медленно, и при
  множестве запросов на сборку (разных модулей, или одного и того же)
  непременно возникнет очередь.

3. Автоматическое выкачивание свежих версий исходников.
  Как хранить данные о том, что и откуда выкачивать?
  Может быть, у вас есть конкретные наработки в этой области.

To be continued...

По каждому из этих пунктов нет однозначно правильного решения, поэтому я и
задаю эти вопросы.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who it's friends are.

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

Re: [devel] Q: cvs inquiry

[Peter Novodvorsky]

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

++ 18/11/00 03:42 +0300 - Dmitry V. Levin:
> Greetings!
> 
> У меня есть небольшой опрос по некоторым аспектам функционирования CVS
> package repository.
> 
> 1. Уведомления о внесении изменений в CVS (o commit'ах).
>   Как следует это организовать, чтобы каждый получал только ту информацию,
>   которая его интересует. Эта система должна быть приспособлена (и даже
>   ориентирована) к появлению новых пакетов.

Сделать файл, в котором написать какие группы пакетов интересуют
конкретного developer. Это в первом приближении. Если все таки
интересует пакет из группы, которая в целом не интересует, можно в
CVS-Package-control (см ниже) добавить поле specially-intrested-developers.

> 
> 2. Сборка исходных и готовых к установке пакетов.
>   Когда это следует делать? Если при commit'е, то при каком именно (при
>   commit'е каких именно файлов)? Если при rtag'е (пока cvs это не умеет),
>   то опять же, когда именно?
IMHO, при rtag должно быть. Так же, можно сделать скриптик, типа
cvs-buildpackage, который по ssh обращается и загружает
соответствующую команду сборки на компьютере. Команда сборки делает
checkout и компилит в нужном месте.

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

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

> 
> 3. Автоматическое выкачивание свежих версий исходников.
>   Как хранить данные о том, что и откуда выкачивать?
Предлагаю сделать файл CVS-Package-control. У него будут поля:

Where-to-get: http://some.where.org/
Version-translate: (скрипт на sed который добавляет версию. Мы это уже
обсуждали кажись...)

Вот.

> По каждому из этих пунктов нет однозначно правильного решения, поэтому я и
> задаю эти вопросы.

Полностью согласен. Дал свои варианты ответов.

Надеюсь, какие-то мысли оказались полезными.

Удачи,
--
Peter Novodvorsky,
IPLabs Linux Team member: petya@logic.ru
Debian developer: nidd@debian.org

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

Re: [devel] Q: cvs inquiry

[Mikhail Zabaluev]

Hello Dmitry,

On Sat, Nov 18, 2000 at 03:42 +0300, Dmitry V. Levin wrote:
>
> Greetings!
> 
> У меня есть небольшой опрос по некоторым аспектам функционирования CVS
> package repository.
> 
> 2. Сборка исходных и готовых к установке пакетов.
>   Когда это следует делать? Если при commit'е, то при каком именно (при
>   commit'е каких именно файлов)? Если при rtag'е (пока cvs это не умеет),
>   то опять же, когда именно?

Можно производить сборку тогда, когда обновляется spec-файл и в
нем меняется номер релиза (или главная часть этого номера).

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

Насколько я понимаю, разные модули все же можно собирать параллельно. Или
это нежелательно из-за нагрузки на машину?

> 3. Автоматическое выкачивание свежих версий исходников.
>   Как хранить данные о том, что и откуда выкачивать?

Если в записях 'Source:' spec-файлов указывать URL там, где только
возможно, и добавить автоматическую подстраховку типа $url.bz2 ->
$url.gz -> $url, я думаю, можно обойтись spec-ами.

-- 
Stay tuned,
  MhZ                                    mailto:mookid@sigent.ru
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] Q: cvs inquiry

[Peter Novodvorsky]

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

Greetings и все такое!

Дполнение к моему предыдущему письму:

++ 18/11/00 14:29 +0300 - Peter Novodvorsky:
> ++ 18/11/00 03:42 +0300 - Dmitry V. Levin:
> > Greetings!
> > 
> > У меня есть небольшой опрос по некоторым аспектам функционирования CVS
> > package repository.
> > 
> > 1. Уведомления о внесении изменений в CVS (o commit'ах).
> >   Как следует это организовать, чтобы каждый получал только ту информацию,
> >   которая его интересует. Эта система должна быть приспособлена (и даже
> >   ориентирована) к появлению новых пакетов.
> 
> Сделать файл, в котором написать какие группы пакетов интересуют
> конкретного developer. Это в первом приближении. Если все таки
> интересует пакет из группы, которая в целом не интересует, можно в
> CVS-Package-control (см ниже) добавить поле specially-intrested-developers.

Еще вариант. CVS-Package-control изначально генерится автоматически. А
потом правится девелоперами. Идея в том, чтобы в CVS-Package-control
было поле
Intrested-developers
которое изначально бы включало всех девелоперов интересующихся группой
пакета. А потом другиедевеолперы могли бы добавлять туда и свои адреса.



--
Peter Novodvorsky,
IPLabs Linux Team member: petya@logic.ru
Debian developer: nidd@debian.org

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

Re: [devel] Q: cvs inquiry

[Peter Novodvorsky]

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

Здраствуйте Михаил!

++ 18/11/00 14:53 +0300 - Mikhail Zabaluev:
> Если в записях 'Source:' spec-файлов указывать URL там, где только
> возможно, и добавить автоматическую подстраховку типа $url.bz2 ->
> $url.gz -> $url, я думаю, можно обойтись spec-ами.
А стоит ли нам по таким пустякам привязываться к RPM -- формату с его
spec-файлами?

--
Peter Novodvorsky,
IPLabs Linux Team member: petya@logic.ru
Debian developer: nidd@debian.org

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

Re: [devel] Q: cvs inquiry

[Mikhail Zabaluev]

Hello Peter,

On Sat, Nov 18, 2000 at 14:29 +0300, Peter Novodvorsky wrote:
>
> ++ 18/11/00 03:42 +0300 - Dmitry V. Levin:
> > Greetings!
> > 
> > У меня есть небольшой опрос по некоторым аспектам функционирования CVS
> > package repository.
> > 
> > 1. Уведомления о внесении изменений в CVS (o commit'ах).
> >   Как следует это организовать, чтобы каждый получал только ту информацию,
> >   которая его интересует. Эта система должна быть приспособлена (и даже
> >   ориентирована) к появлению новых пакетов.
> 
> Сделать файл, в котором написать какие группы пакетов интересуют
> конкретного developer. Это в первом приближении. Если все таки
> интересует пакет из группы, которая в целом не интересует, можно в
> CVS-Package-control (см ниже) добавить поле specially-intrested-developers.

Файл, лучше в XML, или базу данных, с возможностью конфигурировать по Web
настройки для отдельных пользователей. Есть также предположение, что 
RedHat и/или MandrakeSoft уже сделали для себя что-то похожее и, возможно,
горят желанием поделиться этим софтом со всем миром.

-- 
Stay tuned,
  MhZ                                    mailto:mookid@sigent.ru
-----------
JOHN PAUL ELECTED POPE!!

(George and Ringo miffed.)
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] Q: cvs inquiry

[Mikhail Zabaluev]

Hello Peter,

On Sat, Nov 18, 2000 at 15:36 +0300, Peter Novodvorsky wrote:
>
> Здраствуйте Михаил!
> 
> ++ 18/11/00 14:53 +0300 - Mikhail Zabaluev:
> > Если в записях 'Source:' spec-файлов указывать URL там, где только
> > возможно, и добавить автоматическую подстраховку типа $url.bz2 ->
> > $url.gz -> $url, я думаю, можно обойтись spec-ами.
> А стоит ли нам по таким пустякам привязываться к RPM -- формату с его
> spec-файлами?

Чем меньше файлов используется для хранения информации о пакете,
тем лучше. И так уже сделано практически все: в Source можно указывать
URL, чем пользуются многие, в том числе MandrakeSoft. Догадываетесь, что
это они делают неспроста?

-- 
Stay tuned,
  MhZ                                    mailto:mookid@sigent.ru
-----------
Maybe Computer Science should be in the College of Theology.
		-- R. S. Barton
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] Q: cvs inquiry

[Peter Novodvorsky]

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

++ 18/11/00 16:59 +0300 - Mikhail Zabaluev:
> Hello Peter,
> 
> On Sat, Nov 18, 2000 at 15:36 +0300, Peter Novodvorsky wrote:
> >
> > Здраствуйте Михаил!
> > 
> > ++ 18/11/00 14:53 +0300 - Mikhail Zabaluev:
> > > Если в записях 'Source:' spec-файлов указывать URL там, где только
> > > возможно, и добавить автоматическую подстраховку типа $url.bz2 ->
> > > $url.gz -> $url, я думаю, можно обойтись spec-ами.
> > А стоит ли нам по таким пустякам привязываться к RPM -- формату с его
> > spec-файлами?
> 
> Чем меньше файлов используется для хранения информации о пакете,
> тем лучше. И так уже сделано практически все: в Source можно указывать
> URL, чем пользуются многие, в том числе MandrakeSoft. Догадываетесь, что
> это они делают неспроста?

Да, я догадываюсь. Но мне привязка к specам не нравится. Нам нужно не
одно поле, а несколько (в моей концепции). Причем другие поля ну уж
никак не увязываются с сутью spec файлы, они будут специально для
нашего cvs.

--
Peter Novodvorsky,
IPLabs Linux Team member: petya@logic.ru
Debian developer: nidd@debian.org

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

Re: [devel] Q: cvs inquiry

[Mikhail Zabaluev]

Hello Peter,

On Sat, Nov 18, 2000 at 17:30 +0300, Peter Novodvorsky wrote:
>
> > > ++ 18/11/00 14:53 +0300 - Mikhail Zabaluev:
> > > > Если в записях 'Source:' spec-файлов указывать URL там, где только
> > > > возможно, и добавить автоматическую подстраховку типа $url.bz2 ->
> > > > $url.gz -> $url, я думаю, можно обойтись spec-ами.
> > > А стоит ли нам по таким пустякам привязываться к RPM -- формату с его
> > > spec-файлами?
> > 
> > Чем меньше файлов используется для хранения информации о пакете,
> > тем лучше. И так уже сделано практически все: в Source можно указывать
> > URL, чем пользуются многие, в том числе MandrakeSoft. Догадываетесь, что
> > это они делают неспроста?
> 
> Да, я догадываюсь. Но мне привязка к specам не нравится. Нам нужно не
> одно поле, а несколько (в моей концепции). Причем другие поля ну уж
> никак не увязываются с сутью spec файлы, они будут специально для
> нашего cvs.

Например?

-- 
Stay tuned,
  MhZ                                    mailto:mookid@sigent.ru
-----------
QOTD:
	"It's been real and it's been fun, but it hasn't been real fun."
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] Q: cvs inquiry

[Alexander Bokovoy]

Peter Novodvorsky wrote:
> 
> ++ 18/11/00 16:59 +0300 - Mikhail Zabaluev:
> > Hello Peter,
> >
> > On Sat, Nov 18, 2000 at 15:36 +0300, Peter Novodvorsky wrote:
> > >
> > > úÄÒÁÓÔ×ÕÊÔÅ íÉÈÁÉÌ!
> > >
> > > ++ 18/11/00 14:53 +0300 - Mikhail Zabaluev:
> > > > åÓÌÉ × ÚÁÐÉÓÑÈ 'Source:' spec-ÆÁÊÌÏ× ÕËÁÚÙ×ÁÔØ URL ÔÁÍ, ÇÄÅ ÔÏÌØËÏ
> > > > ×ÏÚÍÏÖÎÏ, É ÄÏÂÁ×ÉÔØ Á×ÔÏÍÁÔÉÞÅÓËÕÀ ÐÏÄÓÔÒÁÈÏ×ËÕ ÔÉÐÁ $url.bz2 ->
> > > > $url.gz -> $url, Ñ ÄÕÍÁÀ, ÍÏÖÎÏ ÏÂÏÊÔÉÓØ spec-ÁÍÉ.
> > > á ÓÔÏÉÔ ÌÉ ÎÁÍ ÐÏ ÔÁËÉÍ ÐÕÓÔÑËÁÍ ÐÒÉ×ÑÚÙ×ÁÔØÓÑ Ë RPM -- ÆÏÒÍÁÔÕ Ó ÅÇÏ
> > > spec-ÆÁÊÌÁÍÉ?
> >
> > þÅÍ ÍÅÎØÛÅ ÆÁÊÌÏ× ÉÓÐÏÌØÚÕÅÔÓÑ ÄÌÑ ÈÒÁÎÅÎÉÑ ÉÎÆÏÒÍÁÃÉÉ Ï ÐÁËÅÔÅ,
> > ÔÅÍ ÌÕÞÛÅ. é ÔÁË ÕÖÅ ÓÄÅÌÁÎÏ ÐÒÁËÔÉÞÅÓËÉ ×ÓÅ: × Source ÍÏÖÎÏ ÕËÁÚÙ×ÁÔØ
> > URL, ÞÅÍ ÐÏÌØÚÕÀÔÓÑ ÍÎÏÇÉÅ, × ÔÏÍ ÞÉÓÌÅ MandrakeSoft. äÏÇÁÄÙ×ÁÅÔÅÓØ, ÞÔÏ
> > ÜÔÏ ÏÎÉ ÄÅÌÁÀÔ ÎÅÓÐÒÏÓÔÁ?
> 
> äÁ, Ñ ÄÏÇÁÄÙ×ÁÀÓØ. îÏ ÍÎÅ ÐÒÉ×ÑÚËÁ Ë specÁÍ ÎÅ ÎÒÁ×ÉÔÓÑ. îÁÍ ÎÕÖÎÏ ÎÅ
> ÏÄÎÏ ÐÏÌÅ, Á ÎÅÓËÏÌØËÏ (× ÍÏÅÊ ËÏÎÃÅÐÃÉÉ). ðÒÉÞÅÍ ÄÒÕÇÉÅ ÐÏÌÑ ÎÕ ÕÖ
> ÎÉËÁË ÎÅ Õ×ÑÚÙ×ÁÀÔÓÑ Ó ÓÕÔØÀ spec ÆÁÊÌÙ, ÏÎÉ ÂÕÄÕÔ ÓÐÅÃÉÁÌØÎÏ ÄÌÑ
> ÎÁÛÅÇÏ cvs.
÷ÓÅ-ÔÁËÉ Ñ ÂÙ ÏÓÔÁÎÏ×ÉÌÓÑ ÓÅÊÞÁÓ ÎÁ ÈÒÁÎÅÎÉÉ ÉÎÆÏÒÍÁÃÉÉ ×ÎÕÔÒÉ
spec-ÆÁÊÌÁ. ÷ÒÅÍÅÎÎÙÅ ÏÇÒÁÎÉÞÅÎÉÑ ÎÅÓËÏÌØËÏ ÐÏÄÖÉÍÁÀÔ ÎÁÓ × ×ÙÂÏÒÅ
×ÁÒÉÁÎÔÏ× ÄÌÑ ÐÅÒ×ÏÇÏ ×ÏÐÌÏÝÅÎÉÑ ÉÄÅÉ, Á ÉÓÐÏÌØÚÏ×ÁÎÉÅ ÏÂßÅÄÉÎÅÎÎÏÊ
ÓÉÓÔÅÍÙ ÏÂÌÅÇÞÉÔ ÔÅÓÔÉÒÏ×ÁÎÉÅ.

äÌÑ ÏÐÏ×ÅÝÅÎÉÑ Ï ÏÂÎÏ×ÌÅÎÉÑÈ × ÒÅÐÏÚÉÔÁÒÉÉ ÍÏÖÎÏ ÄÌÑ ÎÁÞÁÌÁ ÐÒÉÎÑÔØ
ÔÁËÏÊ ×ÁÒÉÁÎÔ: ÐÒÉ ÏÔÐÒÁ×ËÅ spec-ÆÁÊÌÁ ÐÏÌÅ Group ÉÓÐÏÌØÚÕÅÔÓÑ ×
ËÁÞÅÓÔ×Å ÇÒÕÐÐÙ ÄÌÑ ÚÁÉÎÔÅÒÅÓÏ×ÁÎÎÙÈ ÒÁÚÒÁÂÏÔÞÉËÏ×, ËÏÔÏÒÙÅ ÄÏÌÖÎÙ
ÐÏÌÕÞÁÔØ ÉÎÆÏÒÍÁÃÉÀ Ï ÜÔÏÍ ÏÂÎÏ×ÌÅÎÉÉ. åÓÌÉ ÕËÁÚÁÎÎÙÊ × spec-ÆÁÊÌÅ
ÍÜÊÎÔÅÊÎÅÒ ÏÔÓÕÔÓÔ×ÕÅÔ × ÔÅËÕÝÅÍ ÓÐÉÓËÅ, ÏÎ ÄÏÂÁ×ÌÑÅÔÓÑ × ÎÅÇÏ. ôÁË, ÐÏ
ËÒÁÊÎÅÊ ÍÅÒÅ, ÍÏÖÎÏ ÉÚÂÅÖÁÔØ ÐÒÏÂÌÅÍ Ó ËÏÏÒÄÉÎÁÃÉÅÊ ÐÒÏÅËÔÏ× ×ÎÕÔÒÉ
ÏÄÎÏÊ ËÁÔÅÇÏÒÉÉ, ÄÁ É ÏÂÒÁÂÁÔÙ×ÁÔØ ÐÒÏÝÅ. îÏ ÜÔÏ ÒÅÛÅÎÉÅ "ÎÁ ÐÅÒ×ÏÅ
×ÒÅÍÑ", ÈÏÔÑ ÅÇÏ ÍÏÖÎÏ É ÒÁÚ×ÉÔØ ÄÁÌÅÅ.
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] Q: cvs inquiry

[Peter Novodvorsky]

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

++ 18/11/00 19:04 +0300 - Mikhail Zabaluev:
> Hello Peter,
> 
> On Sat, Nov 18, 2000 at 17:30 +0300, Peter Novodvorsky wrote:
> > Да, я догадываюсь. Но мне привязка к specам не нравится. Нам нужно не
> > одно поле, а несколько (в моей концепции). Причем другие поля ну уж
> > никак не увязываются с сутью spec файлы, они будут специально для
> > нашего cvs.
> 
> Например?

Например intrested-developers, как я говорил в предыдущем письме.

--
Peter Novodvorsky,
IPLabs Linux Team member: petya@logic.ru
Debian developer: nidd@debian.org

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

Re: [devel] Q: cvs inquiry

[Mikhail Zabaluev]

Hello Alexander,

On Sun, Nov 19, 2000 at 00:56 +0200, Alexander Bokovoy wrote:
>
> > > Чем меньше файлов используется для хранения информации о пакете,
> > > тем лучше. И так уже сделано практически все: в Source можно указывать
> > > URL, чем пользуются многие, в том числе MandrakeSoft. Догадываетесь, что
> > > это они делают неспроста?
> > 
> > Да, я догадываюсь. Но мне привязка к specам не нравится. Нам нужно не
> > одно поле, а несколько (в моей концепции). Причем другие поля ну уж
> > никак не увязываются с сутью spec файлы, они будут специально для
> > нашего cvs.
> Все-таки я бы остановился сейчас на хранении информации внутри
> spec-файла. Временные ограничения несколько поджимают нас в выборе
> вариантов для первого воплощения идеи, а использование объединенной
> системы облегчит тестирование.
> 
> Для оповещения об обновлениях в репозитарии можно для начала принять
> такой вариант: при отправке spec-файла поле Group используется в
> качестве группы для заинтересованных разработчиков, которые должны
> получать информацию об этом обновлении. Если указанный в spec-файле
> мэйнтейнер отсутствует в текущем списке, он добавляется в него. Так, по
> крайней мере, можно избежать проблем с координацией проектов внутри
> одной категории, да и обрабатывать проще. Но это решение "на первое
> время", хотя его можно и развить далее.

Не знаю, имеет ли смысл привязка интересов разработчиков только к группам
RPM. Взять хотя бы Development/C - масса совершенно разных по
тематическому значению пакетов.
Мне кажется, информация о заинтересованных разработчиках все-таки
не является неотъемлемой от пакета, тем более, что она может меняться
чаще, чем пакет. Здесь я согласен с Петром: такие данные, не имеющие
непосредственного представления средствами RPM, лучше конфигурировать
отдельно. На первое же время достаточно будет публиковать все рапорты в
общем списке рассылки - в этом или в специально созданном только для
автоматических объявлений.

-- 
Stay tuned,
  MhZ                                    mailto:mookid@sigent.ru
-----------
He who fights and runs away lives to fight another day.
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] Q: cvs inquiry

[Peter Novodvorsky]

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

++ 21/11/00 00:43 +0300 - Ivan Zakharyaschev:
> 	Hello!
> 
> > > 2. Сборка исходных и готовых к установке пакетов.
> > >   Когда это следует делать? Если при commit'е, то при каком именно
> > (при
> > >   commit'е каких именно файлов)? Если при rtag'е (пока cvs это не
> > умеет),
> > >   то опять же, когда именно?
> > IMHO, при rtag должно быть. Так же, можно сделать скриптик, типа
> > cvs-buildpackage, который по ssh обращается и загружает
> > соответствующую команду сборки на компьютере. Команда сборки делает
> > checkout и компилит в нужном месте.
> 
> Сборка по rtag предусматривает выкладывание пакетов для всех? Хотелось бы
> еще иметь возможность поэкпериментировать со сборкой прежде чем
> выкладывать более-менее официальный релиз.  При совсем плохих сборках
> отсчитывать номера релизов, по-моему, не надо. Да вообще, можно просто
> пробовать собирать что-то совсем странным образом для того, чтобы
> посмотреть, как это работает, а не для последующего выкладывания, или
> готовясь к принципиально другому способу сборки с сильно отличающимся
> spec-файлом, другими патчами.

Я так понимаю, это предполагается делать на локальном компе и не
тратить трафик между билд системой и CVS+FTP, так? ;-) 


					NIDD

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

Re: [devel] Q: cvs inquiry

[Ivan Zakharyaschev]

	Hello!

> > 2. Сборка исходных и готовых к установке пакетов.
> >   Когда это следует делать? Если при commit'е, то при каком именно
> (при
> >   commit'е каких именно файлов)? Если при rtag'е (пока cvs это не
> умеет),
> >   то опять же, когда именно?
> IMHO, при rtag должно быть. Так же, можно сделать скриптик, типа
> cvs-buildpackage, который по ssh обращается и загружает
> соответствующую команду сборки на компьютере. Команда сборки делает
> checkout и компилит в нужном месте.

Сборка по rtag предусматривает выкладывание пакетов для всех? Хотелось бы
еще иметь возможность поэкпериментировать со сборкой прежде чем
выкладывать более-менее официальный релиз.  При совсем плохих сборках
отсчитывать номера релизов, по-моему, не надо. Да вообще, можно просто
пробовать собирать что-то совсем странным образом для того, чтобы
посмотреть, как это работает, а не для последующего выкладывания, или
готовясь к принципиально другому способу сборки с сильно отличающимся
spec-файлом, другими патчами.

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

Как тот, кто запустил сборку, сможет посмотреть на результат/логи? Логи
можно высалать по почте, или хотя бы уведомление о том, что сборка
завершена и где найти логи. Ну да, ничего нового я не предложил, это же и
планировалось.

Можно ли будет, например, "обновить" мои pristine sources XFree до самой
новой их версии, скачивая реально только небольшой diff между ними?
(Может, это и глупый вопрос, но я никогда на работал с удаленным CVS
хранилищем.)

-- 
Best regards,
      Ivan Z.

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

Re: [devel] Q: cvs inquiry

[Dmitry V. Levin]

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

On Tue, Nov 21, 2000 at 12:31:31AM +0300, Peter Novodvorsky wrote:
> > > > 2. Сборка исходных и готовых к установке пакетов.
> > > >   Когда это следует делать? Если при commit'е, то при каком именно
> > > (при
> > > >   commit'е каких именно файлов)? Если при rtag'е (пока cvs это не
> > > умеет),
> > > >   то опять же, когда именно?
> > > IMHO, при rtag должно быть. Так же, можно сделать скриптик, типа
> > > cvs-buildpackage, который по ssh обращается и загружает
> > > соответствующую команду сборки на компьютере. Команда сборки делает
> > > checkout и компилит в нужном месте.
> > 
> > Сборка по rtag предусматривает выкладывание пакетов для всех? Хотелось бы
> > еще иметь возможность поэкпериментировать со сборкой прежде чем
> > выкладывать более-менее официальный релиз.  При совсем плохих сборках
> > отсчитывать номера релизов, по-моему, не надо. Да вообще, можно просто
> > пробовать собирать что-то совсем странным образом для того, чтобы
> > посмотреть, как это работает, а не для последующего выкладывания, или
> > готовясь к принципиально другому способу сборки с сильно отличающимся
> > spec-файлом, другими патчами.
> 
> Я так понимаю, это предполагается делать на локальном компе и не
> тратить трафик между билд системой и CVS+FTP, так? ;-) 

Именно.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who it's friends are.

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

Re: [devel] Q: cvs inquiry

[Peter Novodvorsky]

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

++ 21/11/00 17:32 +0300 - Ivan Zakharyaschev:
> Я все из-за того же XFree: он у меня дома не может собираться, а
> пронаблюдать за сборкой хочется. И собирать я его буду именно с целью
> проверки, а не выкладывания пакета.

Я думаю, в таких экстренных случаях, можно придти в IPLabs, сесть за
photo и собрать. Или зайти на photo по ssh и просто там собрать.
 

						NIDD

--
People ain't no good

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

Re: [devel] Q: cvs inquiry

[Ivan Zakharyaschev]

> Хотелось бы
> > еще иметь возможность поэкпериментировать со сборкой прежде чем
> > выкладывать более-менее официальный релиз.  При совсем плохих сборках
> > отсчитывать номера релизов, по-моему, не надо. Да вообще, можно
> просто
> > пробовать собирать что-то совсем странным образом для того, чтобы
> > посмотреть, как это работает, а не для последующего выкладывания, или
> > готовясь к принципиально другому способу сборки с сильно отличающимся
> > spec-файлом, другими патчами.
>
> Я так понимаю, это предполагается делать на локальном компе и не
> тратить трафик между билд системой и CVS+FTP, так? ;-)

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

-- 
Best regards,
      Ivan Z.

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

Re: [devel] Q: cvs inquiry

[Aleksey Novodvorsky]

Ivan Zakharyaschev wrote:

> > Хотелось бы
> > > еще иметь возможность поэкпериментировать со сборкой прежде чем
> > > выкладывать более-менее официальный релиз.  При совсем плохих сборках
> > > отсчитывать номера релизов, по-моему, не надо. Да вообще, можно
> > просто
> > > пробовать собирать что-то совсем странным образом для того, чтобы
> > > посмотреть, как это работает, а не для последующего выкладывания, или
> > > готовясь к принципиально другому способу сборки с сильно отличающимся
> > > spec-файлом, другими патчами.
> >
> > Я так понимаю, это предполагается делать на локальном компе и не
> > тратить трафик между билд системой и CVS+FTP, так? ;-)
>
> Я все из-за того же XFree: он у меня дома не может собираться, а
> пронаблюдать за сборкой хочется. И собирать я его буду именно с целью
> проверки, а не выкладывания пакета.
>

Если хотите просто понаблюдать -- заходите в гости :-)
А почему не может собираться? Нет места на диске?

Rgrds, Алексей.

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

Re: [devel] Q: cvs inquiry

[Ivan Zakharyaschev]

On Tue, 21 Nov 2000, Aleksey Novodvorsky wrote:

> А почему не может собираться? Нет места на диске?

Да, ничего более хитрого. Но вообще эта проблема решаема.

Я слышал, что все пакеты для RE будут пересобираться. Многие, я так
понимаю, без изменений в spec-файлах. А как будут отличаться имена таких
паетов от оригинальных у Mandrake?

-- 
Best regards,
      Ivan Z.

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

Re: [devel] Q: cvs inquiry

[Peter Novodvorsky]

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

++ 21/11/00 19:28 +0200 - Alexander Bokovoy:
> Ivan Zakharyaschev wrote:
> > 
> > On Tue, 21 Nov 2000, Aleksey Novodvorsky wrote:
> > 
> > > А почему не может собираться? Нет места на диске?
> > 
> > Да, ничего более хитрого. Но вообще эта проблема решаема.
> > 
> > Я слышал, что все пакеты для RE будут пересобираться. Многие, я так
> > понимаю, без изменений в spec-файлах. А как будут отличаться имена таких
> > паетов от оригинальных у Mandrake?
> Префиксом в версии сборки ipl, как и ранее, я думаю. Что касается
> отличий в spec-файлах, то практически везде будут добавляться русские
> группы в Group(ru), так же будут макросы приводиться к нашему
> единообразию. А это (макросы) не так уж и мало -- иногда приходится
> целиком логику SPEC файла переписывать.

Кстати, хорошо бы ввести policy по ведению changelog. Например мне,
изменение "build for RE" ничего не дает. Вобщем-то это и не
изменение. ;-)

					Nidd

--
People ain't no good!

PS. И вообще побольше полисей написать. У Debian есть очень хоррошая
основа для такого документа -- debian packageing policy. Его можно
найти на debian.org.

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

Re: [devel] Q: cvs inquiry

[Alexander Bokovoy]

Ivan Zakharyaschev wrote:
> 
> On Tue, 21 Nov 2000, Aleksey Novodvorsky wrote:
> 
> > á ÐÏÞÅÍÕ ÎÅ ÍÏÖÅÔ ÓÏÂÉÒÁÔØÓÑ? îÅÔ ÍÅÓÔÁ ÎÁ ÄÉÓËÅ?
> 
> äÁ, ÎÉÞÅÇÏ ÂÏÌÅÅ ÈÉÔÒÏÇÏ. îÏ ×ÏÏÂÝÅ ÜÔÁ ÐÒÏÂÌÅÍÁ ÒÅÛÁÅÍÁ.
> 
> ñ ÓÌÙÛÁÌ, ÞÔÏ ×ÓÅ ÐÁËÅÔÙ ÄÌÑ RE ÂÕÄÕÔ ÐÅÒÅÓÏÂÉÒÁÔØÓÑ. íÎÏÇÉÅ, Ñ ÔÁË
> ÐÏÎÉÍÁÀ, ÂÅÚ ÉÚÍÅÎÅÎÉÊ × spec-ÆÁÊÌÁÈ. á ËÁË ÂÕÄÕÔ ÏÔÌÉÞÁÔØÓÑ ÉÍÅÎÁ ÔÁËÉÈ
> ÐÁÅÔÏ× ÏÔ ÏÒÉÇÉÎÁÌØÎÙÈ Õ Mandrake?
ðÒÅÆÉËÓÏÍ × ×ÅÒÓÉÉ ÓÂÏÒËÉ ipl, ËÁË É ÒÁÎÅÅ, Ñ ÄÕÍÁÀ. þÔÏ ËÁÓÁÅÔÓÑ
ÏÔÌÉÞÉÊ × spec-ÆÁÊÌÁÈ, ÔÏ ÐÒÁËÔÉÞÅÓËÉ ×ÅÚÄÅ ÂÕÄÕÔ ÄÏÂÁ×ÌÑÔØÓÑ ÒÕÓÓËÉÅ
ÇÒÕÐÐÙ × Group(ru), ÔÁË ÖÅ ÂÕÄÕÔ ÍÁËÒÏÓÙ ÐÒÉ×ÏÄÉÔØÓÑ Ë ÎÁÛÅÍÕ
ÅÄÉÎÏÏÂÒÁÚÉÀ. á ÜÔÏ (ÍÁËÒÏÓÙ) ÎÅ ÔÁË ÕÖ É ÍÁÌÏ -- ÉÎÏÇÄÁ ÐÒÉÈÏÄÉÔÓÑ
ÃÅÌÉËÏÍ ÌÏÇÉËÕ SPEC ÆÁÊÌÁ ÐÅÒÅÐÉÓÙ×ÁÔØ.
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] Q: cvs inquiry

[Alexander Bokovoy]

Peter Novodvorsky wrote:
> 
> ++ 21/11/00 19:28 +0200 - Alexander Bokovoy:
> > Ivan Zakharyaschev wrote:
> > >
> > > On Tue, 21 Nov 2000, Aleksey Novodvorsky wrote:
> > >
> > > > á ÐÏÞÅÍÕ ÎÅ ÍÏÖÅÔ ÓÏÂÉÒÁÔØÓÑ? îÅÔ ÍÅÓÔÁ ÎÁ ÄÉÓËÅ?
> > >
> > > äÁ, ÎÉÞÅÇÏ ÂÏÌÅÅ ÈÉÔÒÏÇÏ. îÏ ×ÏÏÂÝÅ ÜÔÁ ÐÒÏÂÌÅÍÁ ÒÅÛÁÅÍÁ.
> > >
> > > ñ ÓÌÙÛÁÌ, ÞÔÏ ×ÓÅ ÐÁËÅÔÙ ÄÌÑ RE ÂÕÄÕÔ ÐÅÒÅÓÏÂÉÒÁÔØÓÑ. íÎÏÇÉÅ, Ñ ÔÁË
> > > ÐÏÎÉÍÁÀ, ÂÅÚ ÉÚÍÅÎÅÎÉÊ × spec-ÆÁÊÌÁÈ. á ËÁË ÂÕÄÕÔ ÏÔÌÉÞÁÔØÓÑ ÉÍÅÎÁ ÔÁËÉÈ
> > > ÐÁÅÔÏ× ÏÔ ÏÒÉÇÉÎÁÌØÎÙÈ Õ Mandrake?
> > ðÒÅÆÉËÓÏÍ × ×ÅÒÓÉÉ ÓÂÏÒËÉ ipl, ËÁË É ÒÁÎÅÅ, Ñ ÄÕÍÁÀ. þÔÏ ËÁÓÁÅÔÓÑ
> > ÏÔÌÉÞÉÊ × spec-ÆÁÊÌÁÈ, ÔÏ ÐÒÁËÔÉÞÅÓËÉ ×ÅÚÄÅ ÂÕÄÕÔ ÄÏÂÁ×ÌÑÔØÓÑ ÒÕÓÓËÉÅ
> > ÇÒÕÐÐÙ × Group(ru), ÔÁË ÖÅ ÂÕÄÕÔ ÍÁËÒÏÓÙ ÐÒÉ×ÏÄÉÔØÓÑ Ë ÎÁÛÅÍÕ
> > ÅÄÉÎÏÏÂÒÁÚÉÀ. á ÜÔÏ (ÍÁËÒÏÓÙ) ÎÅ ÔÁË ÕÖ É ÍÁÌÏ -- ÉÎÏÇÄÁ ÐÒÉÈÏÄÉÔÓÑ
> > ÃÅÌÉËÏÍ ÌÏÇÉËÕ SPEC ÆÁÊÌÁ ÐÅÒÅÐÉÓÙ×ÁÔØ.
> 
> ëÓÔÁÔÉ, ÈÏÒÏÛÏ ÂÙ ××ÅÓÔÉ policy ÐÏ ×ÅÄÅÎÉÀ changelog. îÁÐÒÉÍÅÒ ÍÎÅ,
> ÉÚÍÅÎÅÎÉÅ "build for RE" ÎÉÞÅÇÏ ÎÅ ÄÁÅÔ. ÷ÏÂÝÅÍ-ÔÏ ÜÔÏ É ÎÅ
> ÉÚÍÅÎÅÎÉÅ. ;-)
óÍÏÔÒÑ ÞÔÏ ÌÅÖÁÌÏ × ÏÓÎÏ×Å. íÅÖÄÕ MDK É MDK RE -- ×ÏÚÍÏÖÎÏ. ïÄÎÁËÏ
ÚÁÞÁÓÔÕÀ ÍÅÎÑÀÔÓÑ ÐÕÔÉ Ë ÆÁÊÌÁÍ, ÐÏÓËÏÌØËÕ ÔÅËÕÝÉÊ RPM ÉÚ devel
ÓÏÏÔ×ÅÔÓÔ×ÕÅÔ FHS2, Á ÎÁÐÒÉÍÅÒ, ×ÚÑÔÙÊ SPEC ÏÔ RH 6.x (Á ×Ï ÍÎÏÇÉÈ
pristine sources ×ÒÏÄÅ Samba ÏÎÉ É ÅÓÔØ, ÎÅ ÏÔ SuSE ÖÅ ÂÒÁÔØ) ÜÔÏÍÕ ÎÅ
ÕÄÏ×ÌÅÔ×ÏÒÑÅÔ. ðÏÜÔÏÍÕ ÄÁÖÅ ÐÅÒÅÓÂÏÒËÁ ÍÏÖÅÔ ÉÚÍÅÎÉÔØ ÐÁËÅÔ ËÁÒÄÉÎÁÌØÎÏ.

óÅÊÞÁÓ ÜÔÏ ÎÅ ÓÔÏÌØËÏ ÁËÔÕÁÌØÎÏ (ÐÏÞÔÉ Õ ×ÓÅÈ ÄÉÓÔÒÉÂÕÔÉ×Ï× ÕÖÅ ÍÁËÒÏÓ
%configure ÐÒÁ×ÉÌØÎÏ ÒÁÚ×ÏÒÁÞÉ×ÁÅÔÓÑ), ÎÏ ÓÒÁ×ÎÉÔÅ:

%configure --prefix=/usr
É
configure --prefix=/usr

ÄÌÑ ÐÁËÅÔÁ, ËÏÔÏÒÙÊ ÓÔÁ×ÉÔ ÞÔÏ-ÌÉÂÏ × sysconfdir. ÷ ÐÅÒ×ÏÍ ÓÌÕÞÁÅ ÜÔÉ
ÄÁÎÎÙÅ ÐÏÊÄÕÔ × /etc, ×Ï ×ÔÏÒÏÍ -- × /usr/etc
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] Q: cvs inquiry

[Alexander Bokovoy]

Alexander Bokovoy wrote:
> óÅÊÞÁÓ ÜÔÏ ÎÅ ÓÔÏÌØËÏ ÁËÔÕÁÌØÎÏ (ÐÏÞÔÉ Õ ×ÓÅÈ ÄÉÓÔÒÉÂÕÔÉ×Ï× ÕÖÅ ÍÁËÒÏÓ
> %configure ÐÒÁ×ÉÌØÎÏ ÒÁÚ×ÏÒÁÞÉ×ÁÅÔÓÑ), ÎÏ ÓÒÁ×ÎÉÔÅ:
> 
> %configure --prefix=/usr
úÄÅÓØ --prefix ÍÏÖÎÏ ÂÙÌÏ ÏÐÕÓÔÉÔØ, ÎÏ Ñ ÏÓÔÁ×ÉÌ ÅÇÏ ÄÌÑ ÎÁÇÌÑÄÎÏÓÔÉ.

> É
> configure --prefix=/usr
> 
> ÄÌÑ ÐÁËÅÔÁ, ËÏÔÏÒÙÊ ÓÔÁ×ÉÔ ÞÔÏ-ÌÉÂÏ × sysconfdir. ÷ ÐÅÒ×ÏÍ ÓÌÕÞÁÅ ÜÔÉ
> ÄÁÎÎÙÅ ÐÏÊÄÕÔ × /etc, ×Ï ×ÔÏÒÏÍ -- × /usr/etc
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] Q: cvs inquiry

[Dmitry V. Levin]

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

On Tue, Nov 21, 2000 at 05:30:07PM +0300, Peter Novodvorsky wrote:
> > Я все из-за того же XFree: он у меня дома не может собираться, а
> > пронаблюдать за сборкой хочется. И собирать я его буду именно с целью
> > проверки, а не выкладывания пакета.
> 
> Я думаю, в таких экстренных случаях, можно придти в IPLabs, сесть за
> photo и собрать. Или зайти на photo по ssh и просто там собрать.

Все верно. Вот только попасть на photo не так просто (по независящим от
меня причинам).


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who it's friends are.

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

Re: [devel] Q: cvs inquiry

[Dmitry V. Levin]

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

On Mon, Nov 20, 2000 at 12:25:15PM +0300, Mikhail Zabaluev wrote:
> > > > Чем меньше файлов используется для хранения информации о пакете,
> > > > тем лучше. И так уже сделано практически все: в Source можно указывать
> > > > URL, чем пользуются многие, в том числе MandrakeSoft. Догадываетесь, что
> > > > это они делают неспроста?
> > > 
> > > Да, я догадываюсь. Но мне привязка к specам не нравится. Нам нужно не
> > > одно поле, а несколько (в моей концепции). Причем другие поля ну уж
> > > никак не увязываются с сутью spec файлы, они будут специально для
> > > нашего cvs.
> > Все-таки я бы остановился сейчас на хранении информации внутри
> > spec-файла. Временные ограничения несколько поджимают нас в выборе
> > вариантов для первого воплощения идеи, а использование объединенной
> > системы облегчит тестирование.
> > 
> > Для оповещения об обновлениях в репозитарии можно для начала принять
> > такой вариант: при отправке spec-файла поле Group используется в
> > качестве группы для заинтересованных разработчиков, которые должны
> > получать информацию об этом обновлении. Если указанный в spec-файле
> > мэйнтейнер отсутствует в текущем списке, он добавляется в него. Так, по
> > крайней мере, можно избежать проблем с координацией проектов внутри
> > одной категории, да и обрабатывать проще. Но это решение "на первое
> > время", хотя его можно и развить далее.
> 
> Не знаю, имеет ли смысл привязка интересов разработчиков только к группам
> RPM. Взять хотя бы Development/C - масса совершенно разных по
> тематическому значению пакетов.

Это верно.

> Мне кажется, информация о заинтересованных разработчиках все-таки
> не является неотъемлемой от пакета, тем более, что она может меняться
> чаще, чем пакет. Здесь я согласен с Петром: такие данные, не имеющие
> непосредственного представления средствами RPM, лучше конфигурировать

Даже данные по закачке исходников сложно уместить в spec-файл без
добавления новых тэгов (или псевдотэгов).
Пример из cvs.spec:
Source: ftp://ftp.cvshome.org/pub/%name-%version/%name-%version.tar.bz2

Наиболее разумно держать информацию для уведомлений в базе данных и
управлять через web (ибо пакетов сотни). Единственная проблема - на
сервере logic.ru совершенно не заинтересованный ни в чем подобном и потому
совершенно непрошибаемый администратор (Вы, наверное, об этом уже
догадались) - там нет никакого сервера базы данных; а если будет - то
очень не скоро, и не тот, который нужен, и не та версия, которая работает, и ...

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

Не будет списка рассылки как такового - по нему нельзя будет ничего
послать, только получить. Впрочем, это уже детали.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who it's friends are.

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

[devel] Q: changelog policy

[Dmitry V. Levin]

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

On Tue, Nov 21, 2000 at 08:15:39PM +0300, Peter Novodvorsky wrote:
> > > Я слышал, что все пакеты для RE будут пересобираться. Многие, я так
> > > понимаю, без изменений в spec-файлах. А как будут отличаться имена таких
> > > паетов от оригинальных у Mandrake?
> > Префиксом в версии сборки ipl, как и ранее, я думаю. Что касается
> > отличий в spec-файлах, то практически везде будут добавляться русские
> > группы в Group(ru), так же будут макросы приводиться к нашему
> > единообразию. А это (макросы) не так уж и мало -- иногда приходится
> > целиком логику SPEC файла переписывать.
> 
> Кстати, хорошо бы ввести policy по ведению changelog. Например мне,
> изменение "build for RE" ничего не дает. Вобщем-то это и не
> изменение. ;-)

До апреля этого года я писал просто и лаконично:
- Fandra adaptions.

Примерно с апреля-мая заменил эту емкую фразу на
- RE adaptions.

На самом деле так, конечно, делать нельзя, и от подобной практики я уже
отказался. Выработались некие негласные правила:
+ Если spec-файл новый, ограничится одной строкой
  - Initial revision.
+ Если произведена конвертация из другого дистрибутива, добавить
  - RE adaptions.
+ Если предыдущая версия spec-файла не была FHS-совместима, добавить
  - FHSification.
+ Если была проведена адаптация texinfo-файлов, добавить
  - Fixed texinfo documentation.
+ Если была произведена адаптация к новым особенностям pam, xinetd, ...
  явно указать это.
+ Если Вы являетесь maintainer'ом пакета в полном смысле этого слова,
  стоит добавить changelog-информацию по существу (если она не отражена в
  отдельном файле).
+ ... (вспомню - добавлю).

Я постараюсь проанализировать свои spec-файлы и предложить нечто вроде
writing changelog policy. Пока что пожелания приветствуются.

> PS. И вообще побольше полисей написать. У Debian есть очень хоррошая
> основа для такого документа -- debian packageing policy. Его можно
> найти на debian.org.

И побольше maintainer'ов, которые этим policy будут следовать. :)
А Вы пишите - обсудим.

На самом деле, я уже пробовал сделать нечто подобное; оно, правда,
морально устарело, пора делать новую версию.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who it's friends are.

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

Re: [devel] Q: cvs inquiry

[Dmitry V. Levin]

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

On Wed, Nov 22, 2000 at 05:22:50AM +0300, Aleksey Novodvorsky wrote:
> > > > Я все из-за того же XFree: он у меня дома не может собираться, а
> > > > пронаблюдать за сборкой хочется. И собирать я его буду именно с целью
> > > > проверки, а не выкладывания пакета.
> > >
> > > Я думаю, в таких экстренных случаях, можно придти в IPLabs, сесть за
> > > photo и собрать. Или зайти на photo по ssh и просто там собрать.
> >
> > Все верно. Вот только попасть на photo не так просто (по независящим от
> > меня причинам).
> >
> 
> Попасть  сложно -- лично или по ssh?

Кому как:
- Мне сложно попасть лично - до IPLabs час езды.
- У кого нет доступа на grand - сложно попасть по ssh.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who it's friends are.

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

Re: [devel] Q: cvs inquiry

[Aleksey Novodvorsky]

"Dmitry V. Levin" wrote:

> On Tue, Nov 21, 2000 at 05:30:07PM +0300, Peter Novodvorsky wrote:
> > > Я все из-за того же XFree: он у меня дома не может собираться, а
> > > пронаблюдать за сборкой хочется. И собирать я его буду именно с целью
> > > проверки, а не выкладывания пакета.
> >
> > Я думаю, в таких экстренных случаях, можно придти в IPLabs, сесть за
> > photo и собрать. Или зайти на photo по ssh и просто там собрать.
>
> Все верно. Вот только попасть на photo не так просто (по независящим от
> меня причинам).
>

Попасть  сложно -- лично или по ssh?

Rgrds, AEN

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

Re: [devel] Q: cvs inquiry

[Aleksey Novodvorsky]

"Dmitry V. Levin" wrote:

> On Mon, Nov 20, 2000 at 12:25:15PM +0300, Mikhail Zabaluev wrote:
> > > > > Чем меньше файлов используется для хранения информации о пакете,
> > > > > тем лучше. И так уже сделано практически все: в Source можно указывать
> > > > > URL, чем пользуются многие, в том числе MandrakeSoft. Догадываетесь, что
> > > > > это они делают неспроста?
> > > >
> > > > Да, я догадываюсь. Но мне привязка к specам не нравится. Нам нужно не
> > > > одно поле, а несколько (в моей концепции). Причем другие поля ну уж
> > > > никак не увязываются с сутью spec файлы, они будут специально для
> > > > нашего cvs.
> > > Все-таки я бы остановился сейчас на хранении информации внутри
> > > spec-файла. Временные ограничения несколько поджимают нас в выборе
> > > вариантов для первого воплощения идеи, а использование объединенной
> > > системы облегчит тестирование.
> > >
> > > Для оповещения об обновлениях в репозитарии можно для начала принять
> > > такой вариант: при отправке spec-файла поле Group используется в
> > > качестве группы для заинтересованных разработчиков, которые должны
> > > получать информацию об этом обновлении. Если указанный в spec-файле
> > > мэйнтейнер отсутствует в текущем списке, он добавляется в него. Так, по
> > > крайней мере, можно избежать проблем с координацией проектов внутри
> > > одной категории, да и обрабатывать проще. Но это решение "на первое
> > > время", хотя его можно и развить далее.
> >
> > Не знаю, имеет ли смысл привязка интересов разработчиков только к группам
> > RPM. Взять хотя бы Development/C - масса совершенно разных по
> > тематическому значению пакетов.
>
> Это верно.
>
> > Мне кажется, информация о заинтересованных разработчиках все-таки
> > не является неотъемлемой от пакета, тем более, что она может меняться
> > чаще, чем пакет. Здесь я согласен с Петром: такие данные, не имеющие
> > непосредственного представления средствами RPM, лучше конфигурировать
>
> Даже данные по закачке исходников сложно уместить в spec-файл без
> добавления новых тэгов (или псевдотэгов).
> Пример из cvs.spec:
> Source: ftp://ftp.cvshome.org/pub/%name-%version/%name-%version.tar.bz2
>
> Наиболее разумно держать информацию для уведомлений в базе данных и
> управлять через web (ибо пакетов сотни). Единственная проблема - на
> сервере logic.ru совершенно не заинтересованный ни в чем подобном и потому
> совершенно непрошибаемый администратор (Вы, наверное, об этом уже
> догадались) - там нет никакого сервера базы данных; а если будет - то
> очень не скоро, и не тот, который нужен, и не та версия, которая работает, и ...
>

На следующей неделе  должен войти в строй еще один сервер. Администратор там будет
прошибаемый :-)
Лучше поздно...

Rgrds, Алексей.

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

Re: [devel] Q: cvs inquiry

[Mikhail Zabaluev]

Hello Dmitry,

On Wed, Nov 22, 2000 at 03:07 +0300, Dmitry V. Levin wrote:
>
> Даже данные по закачке исходников сложно уместить в spec-файл без
> добавления новых тэгов (или псевдотэгов).
> Пример из cvs.spec:
> Source: ftp://ftp.cvshome.org/pub/%name-%version/%name-%version.tar.bz2

Смущают макросы? А опция -bE на что?

-- 
Stay tuned,
  MhZ                                    mailto:mookid@sigent.ru
-----------
All syllogisms have three parts, therefore this is not a syllogism.
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] Q: cvs inquiry

[Dmitry V. Levin]

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

On Wed, Nov 22, 2000 at 06:56:42AM +0300, Mikhail Zabaluev wrote:
> > Даже данные по закачке исходников сложно уместить в spec-файл без
> > добавления новых тэгов (или псевдотэгов).
> > Пример из cvs.spec:
> > Source: ftp://ftp.cvshome.org/pub/%name-%version/%name-%version.tar.bz2
> 
> Смущают макросы? А опция -bE на что?

Дело не в макросах, а в шаблоне поиска новых файлов на сайте, который из
URL'а не выводится очевидным образом.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who it's friends are.

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

Re: [devel] Q: cvs inquiry

[Mikhail Zabaluev]

Hello Dmitry,

On Wed, Nov 22, 2000 at 08:51 +0300, Dmitry V. Levin wrote:
>
> On Wed, Nov 22, 2000 at 06:56:42AM +0300, Mikhail Zabaluev wrote:
> > > Даже данные по закачке исходников сложно уместить в spec-файл без
> > > добавления новых тэгов (или псевдотэгов).
> > > Пример из cvs.spec:
> > > Source: ftp://ftp.cvshome.org/pub/%name-%version/%name-%version.tar.bz2
> > 
> > Смущают макросы? А опция -bE на что?
> 
> Дело не в макросах, а в шаблоне поиска новых файлов на сайте, который из
> URL'а не выводится очевидным образом.

Не понимаю. Если в 'Source:' задан URL с точностью плюс-минус архивный
суффикс, то и искать ничего не нужно. Если имеется в виду поиск локальных
файлов, то их имена из URL вычленить тоже не представляется сложным -
rpm ведь справляется.

-- 
Stay tuned,
  MhZ                                    mailto:mookid@sigent.ru
-----------
I've been in more laps than a napkin.
		-- Mae West
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] Q: cvs inquiry

[Dmitry V. Levin]

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

On Wed, Nov 22, 2000 at 09:19:06AM +0300, Mikhail Zabaluev wrote:
> > > > Даже данные по закачке исходников сложно уместить в spec-файл без
> > > > добавления новых тэгов (или псевдотэгов).
> > > > Пример из cvs.spec:
> > > > Source: ftp://ftp.cvshome.org/pub/%name-%version/%name-%version.tar.bz2
> > > 
> > > Смущают макросы? А опция -bE на что?
> > 
> > Дело не в макросах, а в шаблоне поиска новых файлов на сайте, который из
> > URL'а не выводится очевидным образом.
> 
> Не понимаю. Если в 'Source:' задан URL с точностью плюс-минус архивный
> суффикс, то и искать ничего не нужно. Если имеется в виду поиск локальных
> файлов, то их имена из URL вычленить тоже не представляется сложным -
> rpm ведь справляется.

Очень просто:
Когда URL записан в виде
ftp://ftp.cvshome.org/pub/%name-%version/%name-%version.tar.bz2,
то мне очевидно, что в поиске свежей версии требуется найти все
ftp://ftp.cvshome.org/pub/cvs-*/cvs-*.tar.gz, отсортировать по номеру
версии, найдя, таким образом, самую свежую, которую и скачать. Слабо
написать алгоритм, который сможет реализовать подобные схемы, пользуясь
_только_ знанием URL'а?

Другое дело, если есть не голый URL, а готовый шаблон для поиска.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who it's friends are.

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

Re: [devel] Q: cvs inquiry

[Mikhail Zabaluev]

Hello Dmitry,

On Thu, Nov 23, 2000 at 23:52 +0300, Dmitry V. Levin wrote:
>
> > Не понимаю. Если в 'Source:' задан URL с точностью плюс-минус архивный
> > суффикс, то и искать ничего не нужно. Если имеется в виду поиск локальных
> > файлов, то их имена из URL вычленить тоже не представляется сложным -
> > rpm ведь справляется.
> 
> Очень просто:
> Когда URL записан в виде
> ftp://ftp.cvshome.org/pub/%name-%version/%name-%version.tar.bz2,
> то мне очевидно, что в поиске свежей версии требуется найти все
> ftp://ftp.cvshome.org/pub/cvs-*/cvs-*.tar.gz, отсортировать по номеру
> версии, найдя, таким образом, самую свежую, которую и скачать. Слабо
> написать алгоритм, который сможет реализовать подобные схемы, пользуясь
> _только_ знанием URL'а?

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

Еще есть мысли по поводу репозитория. На первое время можно отказаться от
автоматической сборки на том же сервере, где находится публичное
CVS-дерево. Можно и вообще отказаться, если выделить машину, которая будет
регулярно делать update с этого CVS и собирать измененные пакеты у себя. И
вообще - у кого нет машины, чтобы тестировать свои пакеты, поднимите руку
:) (Хотя, вопрос скорее в толщине и дороговизне пуповины-Интернета).
А пробивать /dev/zero и /dev/shmero у админов, у которых одна мысль о том,
что в систему будут закачиваться мегабайты неизвестно чего и потом
что-то из этого будет запускаться на исполнение, вызывает икоту - долгая
история.

Кстати, об икоте: есть ли идеи насчет автоматической проверки подлинности
исходников? Скажем, верификации сигнатур там, где они есть?

-- 
Stay tuned,
  MhZ                                    mailto:mookid@sigent.ru
-----------
If you're carrying a torch, put it down.  The Olympics are over.
_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

Re: [devel] Q: cvs inquiry

[Dmitry V. Levin]

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

On Fri, Nov 24, 2000 at 01:30:23AM +0300, Mikhail Zabaluev wrote:
> > > Не понимаю. Если в 'Source:' задан URL с точностью плюс-минус архивный
> > > суффикс, то и искать ничего не нужно. Если имеется в виду поиск локальных
> > > файлов, то их имена из URL вычленить тоже не представляется сложным -
> > > rpm ведь справляется.
> > 
> > Очень просто:
> > Когда URL записан в виде
> > ftp://ftp.cvshome.org/pub/%name-%version/%name-%version.tar.bz2,
> > то мне очевидно, что в поиске свежей версии требуется найти все
> > ftp://ftp.cvshome.org/pub/cvs-*/cvs-*.tar.gz, отсортировать по номеру
> > версии, найдя, таким образом, самую свежую, которую и скачать. Слабо
> > написать алгоритм, который сможет реализовать подобные схемы, пользуясь
> > _только_ знанием URL'а?
> 
> Во имя всего святого, зачем? За обновлением версий пусть следит
> maintainer. Не для роботов это - решать, какие исходники пойдут в дело.
> Может, в этом месте еще нестабильных версий навалено, откуда знать?

Некоторые дистрибутивы так делают, и это имеет смысл, особенно когда на
одного miantainer'а приходится более сотни пакетов *sigh*

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

И в мыслях не было!

Это просто невозможно - собирать и тестировать пакеты на живом сервере.

> CVS-дерево. Можно и вообще отказаться, если выделить машину, которая будет
> регулярно делать update с этого CVS и собирать измененные пакеты у себя. И

Так и было задумано, только я полагаю, что разумнее все-таки осуществлять
сборку по инициативе packager'а.

> вообще - у кого нет машины, чтобы тестировать свои пакеты, поднимите руку
> :) (Хотя, вопрос скорее в толщине и дороговизне пуповины-Интернета).
> А пробивать /dev/zero и /dev/shmero у админов, у которых одна мысль о том,
> что в систему будут закачиваться мегабайты неизвестно чего и потом
> что-то из этого будет запускаться на исполнение, вызывает икоту - долгая
> история.

Об этом и речи не было, чтобы закачиваемое на сервер там запускалось (см.
выше).

> Кстати, об икоте: есть ли идеи насчет автоматической проверки подлинности
> исходников? Скажем, верификации сигнатур там, где они есть?

Я всегда это делаю.
Автоматическая проверка вряд ли годится, а вот maintainer'ская вполне
разумна.

Предполагается, что maintainer проверяет подписи у себя перед началом
сборки, а перед commit'ом убеждается, что у него и на удаленном
CVS-сервере оказались одинаковые файлы (закаченные разными путями)
посредством md5sum.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who it's friends are.

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