[devel] repocop на sisyphus.ru

[devel] repocop на sisyphus.ru

[Andrew Avramenko]

Добрый день!


Отчеты repocop теперь доступны на sisyphus.ru.


-- 
With best regards,
Andrew

[devel] repocop на sisyphus.ru [qualified]

[Igor Vlasenko]

On Mon, Jul 07, 2008 at 10:17:21AM +0400, Andrew Avramenko wrote:
> Добрый день!
> Отчеты repocop теперь доступны на sisyphus.ru.
Уточнение!
По техническим причинам вчера там были старые результаты 
с ftp.linux.kiev.ua 2-х месячной давности.

Это исправлено, с настоящего момента там доступны 
свежие результаты с repocop.altlinux.org.

Также сейчас там показывается много лишних (пустых) патчей.
Это будет исправлено завтра.

Приглашаем всех посмотреть свои пакеты.
-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] repocop на sisyphus.ru [qualified]

[Alexey I. Froloff]

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

* Igor Vlasenko <vlasenko@> [080707 16:12]:
> Это исправлено, с настоящего момента там доступны 
> свежие результаты с repocop.altlinux.org.
Я уже писал, что пакет scummvm соответствует Icons Policy.
Поправьте тест, пожалуйста.

Можно наконец заткнуть тест на %update_desktopdb и решить
проблему по человечески?

-- 
Regards,
Sir Raorn.

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

Re: [devel] repocop на sisyphus.ru

[Alexey I. Froloff]

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

* Andrew Avramenko <liks@> [080707 10:20]:
> Отчеты repocop теперь доступны на sisyphus.ru.
Нечитаемо.  "Репозитории ALT" перекрывают центральную треть
каментов.


-- 
Regards,
Sir Raorn.

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

Re: [devel] repocop на sisyphus.ru [qualified]

[Igor Vlasenko]

On Mon, Jul 07, 2008 at 04:32:14PM +0400, Alexey I. Froloff wrote:
> * Igor Vlasenko <vlasenko@> [080707 16:12]:
> > Это исправлено, с настоящего момента там доступны 
> > свежие результаты с repocop.altlinux.org.
> Я уже писал, что пакет scummvm соответствует Icons Policy.
> Поправьте тест, пожалуйста.

%_liconsdir, %_niconsdir, %_miconsdir нет.
Так что полиси не соблюдается - с одной стороны.
С другой стороны это же репокоп, а не сизифус-чек --
Вы всегда можете игнорировать эти сообщения.

> Можно наконец заткнуть тест на %update_desktopdb и решить
> проблему по человечески?

Это не ко мне, к сожалению :(

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] repocop на sisyphus.ru [qualified]

[Michael Shigorin]

On Mon, Jul 07, 2008 at 03:04:13PM +0300, Igor Vlasenko wrote:
> On Mon, Jul 07, 2008 at 10:17:21AM +0400, Andrew Avramenko wrote:
> > Отчеты repocop теперь доступны на sisyphus.ru.
> [...] с настоящего момента там доступны свежие результаты
> с repocop.altlinux.org.

Спасибо!

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

Re: [devel] repocop на sisyphus.ru [qualified]

[Alexey I. Froloff]

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

* Igor Vlasenko <vlasenko@> [080707 16:42]:
> > > Это исправлено, с настоящего момента там доступны 
> > > свежие результаты с repocop.altlinux.org.
> > Я уже писал, что пакет scummvm соответствует Icons Policy.
> > Поправьте тест, пожалуйста.
> %_liconsdir, %_niconsdir, %_miconsdir нет.
> Так что полиси не соблюдается - с одной стороны.
Я показывал цитату из полиси.  Соблюдается.

> > Можно наконец заткнуть тест на %update_desktopdb и решить
> > проблему по человечески?
> Это не ко мне, к сожалению :(
А к кому?

-- 
Regards,
Sir Raorn.

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

Re: [devel] repocop на sisyphus.ru [qualified]

[Igor Vlasenko]

On Mon, Jul 07, 2008 at 05:33:43PM +0400, Alexey I. Froloff wrote:
> > > Можно наконец заткнуть тест на %update_desktopdb и решить
> > > проблему по человечески?
> > Это не ко мне, к сожалению :(
> А к кому?

К неизвестному добровольцу.
Эта проблема не раз обсуждалась, и наиболее красивый вариант -
вставить обработку многих %post/un событий в librpm
основываясь на шаблонах имени файла.



-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] repocop на sisyphus.ru [qualified]

[Alexey I. Froloff]

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

* Igor Vlasenko <vlasenko@> [080707 20:43]:
> > > > Можно наконец заткнуть тест на %update_desktopdb и решить
> > > > проблему по человечески?
> > > Это не ко мне, к сожалению :(
> > А к кому?
> К неизвестному добровольцу.
Так вот пока этот доброволец не появился, прошу отключить этот
тест.


-- 
Regards,
Sir Raorn.

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

Re: [devel] repocop на sisyphus.ru [qualified]

[Igor Vlasenko]

On Mon, Jul 07, 2008 at 09:24:02PM +0400, Alexey I. Froloff wrote:
> * Igor Vlasenko <vlasenko@> [080707 20:43]:
> > > > > Можно наконец заткнуть тест на %update_desktopdb и решить
> > > > > проблему по человечески?
> > > > Это не ко мне, к сожалению :(
> > > А к кому?
> > К неизвестному добровольцу.
> Так вот пока этот доброволец не появился, прошу отключить этот
> тест.

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

Приложите, пожалуйста 
/var/ftp/pub/repocop/reports/diff/by-packager/raorn/azureus-3.0.4.2-alt2.diff
и забудьте про этот тест.

Это не правильно, критиковать, ничего не делая.
Вызовитесь добровольцем, реализуйте наконец эту фичу, 
и show us your code.
А то я трудился, писал репокоп, писал патч, 
а вы его даже приложить не хотите.

:(

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] repocop на sisyphus.ru [qualified]

[Alexey I. Froloff]

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

* Igor Vlasenko <vlasenko@> [080707 21:53]:
> Когда ее можно будет достичь другим способом, я с удовольствием
> этот тест уберу.
Я уже говорил как можно этого достичь другим способом.

> Приложите, пожалуйста 
> /var/ftp/pub/repocop/reports/diff/by-packager/raorn/azureus-3.0.4.2-alt2.diff
> и забудьте про этот тест.
Я не буду прикладывать этот патч и уже неоднократно об'яснял
почему.

> А то я трудился, писал репокоп, писал патч, а вы его даже
> приложить не хотите.

    - Вывод, - сказал я. - описанная машина "ремингтон" в
соединении с выпрямителем, неоновой лампочкой, тумблером и шнуром
не содержит ничего необ'ясненного.
    - А я? - вскричал старичок.
    Эдик показал мне, как надлежит делать хук слева, но это я не
мог.
    - Нет, конечно... - промямлил я. - проделана большая
работа... /Эдик схватился за голову/, я, конечно, понимаю...
Добрые намерения... /Эдик посмотрел на меня с презрением/. Ну в
самом деле, сказал я. - человек старался... Нельзя же так....
    - Побойся бога, - отчетливо произнес Эдик.
    - Нет... Ну что ж... Ну, пусть человек работает, раз ему
интересно. Я только говорю, что необ'ясненного нет...  Вообще-то
даже остроумно...

-- 
Regards,
Sir Raorn.

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

Re: [devel] repocop на sisyphus.ru [qualified]

[Dmitry V. Levin]

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

On Mon, Jul 07, 2008 at 10:07:30PM +0400, Alexey I. Froloff wrote:
> * Igor Vlasenko <vlasenko@> [080707 21:53]:
> > Когда ее можно будет достичь другим способом, я с удовольствием
> > этот тест уберу.
> Я уже говорил как можно этого достичь другим способом.
> 
> > Приложите, пожалуйста 
> > /var/ftp/pub/repocop/reports/diff/by-packager/raorn/azureus-3.0.4.2-alt2.diff
> > и забудьте про этот тест.
> Я не буду прикладывать этот патч и уже неоднократно об'яснял
> почему.

Тогда объясни ещё раз или приведи ссылку.
Ибо тест, который ты критикуешь, выявляет проблемы.

> > А то я трудился, писал репокоп, писал патч, а вы его даже
> > приложить не хотите.
> 
>     - Вывод, - сказал я. - описанная машина "ремингтон" в

Ерунда, останется несмываемым пятном на твоей совести. :(
Лучше бы сделал вид, что до тебя не доходит почта.


-- 
ldv

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

Re: [devel] repocop на sisyphus.ru [qualified]

[Mikhail Gusarov]

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

Twas brillig at 22:27:09 07.07.2008 UTC+04 when ldv@altlinux.org did gyre and gimble:

 DVL> Тогда объясни ещё раз или приведи ссылку.  Ибо тест, который ты
 DVL> критикуешь, выявляет проблемы.

Как я понимаю, raorn против решения проблемы с отсутствующим
update_desktopdb с помощью его добавления.

Аргумент достаточно простой: аналогичным образом можно было бы добавить
удаление buildroot, ручную установку BuildRoot в спеке и т.д., однако
эти проблемы были решены не разбуханием спеков, а исправлением скриптов
RPM.

Аналогично, проблема с отсутствующим update_desktopdb должна быть решена
системно: одним (!) макросом для postinst/prerm, который занимается
менеджментом .desktop-файлов: как mime-entries, так и menu, причём
самостоятельно, а не напрягая мозг майнтайнера.

Поскольку вся необходимая логика уже есть в тесте repocop (как-то же он
находит отсутствующий update_desktopdb?), то такой макрос соорудить не
представляется особо сложным.

-- 

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

Re: [devel] repocop на sisyphus.ru [qualified]

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [080707 22:34]:
> > Я не буду прикладывать этот патч и уже неоднократно об'яснял
> > почему.
> Тогда объясни ещё раз или приведи ссылку.
> Ибо тест, который ты критикуешь, выявляет проблемы.
Я не понимаю зачем мне из-за одного .desktop файла вызывать в
%post два макроса %update_menus и %update_desktopdb.  Что мешает
"слить" их в один?  В этом случае я с удовольствием разрешу NMU
для пересборки с этим одним новым макросом.

Кстати, Дим, посмотри два коммита у меня в
rpm.git/onetime-pdeath.

-- 
Regards,
Sir Raorn.

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

Re: [devel] repocop на sisyphus.ru [qualified]

[Mikhail Gusarov]

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

Twas brillig at 01:33:23 08.07.2008 UTC+07 when dottedmag@dottedmag.net did gyre and gimble:

 DVL>> Тогда объясни ещё раз или приведи ссылку.  Ибо тест, который ты
 DVL>> критикуешь, выявляет проблемы.

 MG> Как я понимаю, raorn против решения проблемы с отсутствующим
 MG> update_desktopdb с помощью его добавления.

[]

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

- отсутствующий хэндлер регистрации mime-обработчика
- отсутствующий мегамакрос, делающий всю работу сам.

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

-- 

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

Re: [devel] repocop на sisyphus.ru [qualified]

[Yuri N. Sedunov]

В Втр, 08/07/2008 в 01:33 +0700, Mikhail Gusarov пишет:
> Twas brillig at 22:27:09 07.07.2008 UTC+04 when ldv@altlinux.org did gyre and gimble:
> 
<skip>
> 
> Аналогично, проблема с отсутствующим update_desktopdb должна быть решена
> системно: одним (!) макросом для postinst/prerm, который занимается
> менеджментом .desktop-файлов: как mime-entries, так и menu, причём
> самостоятельно, а не напрягая мозг майнтайнера.

+100, может лучше даже начать с %post{,un}_ldconfig


-- 
Yuri N. Sedunov

Re: [devel] repocop на sisyphus.ru [qualified]

[Alexey I. Froloff]

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

* Igor Vlasenko <vlasenko@> [080707 21:53]:
> Это не правильно, критиковать, ничего не делая.
> Вызовитесь добровольцем, реализуйте наконец эту фичу, 
> и show us your code.
rpm.git/desktopdb.  И не надо ничего патчить, а потом
распатчивать.

-- 
Regards,
Sir Raorn.

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

Re: [devel] repocop на sisyphus.ru [qualified]

[Igor Vlasenko]

On Tue, Jul 08, 2008 at 12:25:00AM +0400, Alexey I. Froloff wrote:
> > Вызовитесь добровольцем, реализуйте наконец эту фичу, 
> > и show us your code.
> rpm.git/desktopdb.  И не надо ничего патчить, а потом
> распатчивать.

Вот это мужской подход!
С нетерпением жду официального анонса.
А что еще (ldconfig...) можно туда прикрутить?


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] repocop на sisyphus.ru [qualified]

[Dmitry V. Levin]

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

On Tue, Jul 08, 2008 at 12:25:00AM +0400, Alexey I. Froloff wrote:
> * Igor Vlasenko <vlasenko@> [080707 21:53]:
> > Это не правильно, критиковать, ничего не делая.
> > Вызовитесь добровольцем, реализуйте наконец эту фичу, 
> > и show us your code.
> rpm.git/desktopdb.  И не надо ничего патчить, а потом
> распатчивать.

Только, пожалуйста, не @mandrake@ ;)


-- 
ldv

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

Re: [devel] repocop на sisyphus.ru [qualified]

[Alexey I. Froloff]

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

* Igor Vlasenko <vlasenko@> [080708 00:50]:
> > rpm.git/desktopdb.  И не надо ничего патчить, а потом
> > распатчивать.
> Вот это мужской подход!
> С нетерпением жду официального анонса.
> А что еще (ldconfig...) можно туда прикрутить?
Куда - туда?  Это не то, это просто об'единение %update_menus и
%update_desktopdb в один макрос.  Чтобы работало "прямщас" и не
надо было 150 пакетов патчить.

-- 
Regards,
Sir Raorn.

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

Re: [devel] repocop на sisyphus.ru [qualified]

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [080708 01:00]:
> > rpm.git/desktopdb.  И не надо ничего патчить, а потом
> > распатчивать.
> Только, пожалуйста, не @mandrake@ ;)
То-то мне содержимое макроса показалось кривоватым...

-- 
Regards,
Sir Raorn.

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

Re: [devel] /var/lock/rpm/update-vimhelp

[Dmitry V. Levin]

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

On Mon, Jul 07, 2008 at 10:40:50PM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [080707 22:34]:
> > > Я не буду прикладывать этот патч и уже неоднократно об'яснял
> > > почему.
> > Тогда объясни ещё раз или приведи ссылку.
> > Ибо тест, который ты критикуешь, выявляет проблемы.
> Я не понимаю зачем мне из-за одного .desktop файла вызывать в
> %post два макроса %update_menus и %update_desktopdb.  Что мешает
> "слить" их в один?  В этом случае я с удовольствием разрешу NMU
> для пересборки с этим одним новым макросом.
> 
> Кстати, Дим, посмотри два коммита у меня в
> rpm.git/onetime-pdeath.

Это выглядит лишним, почти то же самое можно сделать с помощью flock(1),
например,
%_rpmlibdir/pdeath_execute $PPID flock -n /var/lock/rpm/update-vimhelp -c 'update-vimhelp %_bindir/update-vimhelp'
Хотя в таком простом варианте есть race.


-- 
ldv

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

Re: [devel] /var/lock/rpm/update-vimhelp

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [080708 03:32]:
> Это выглядит лишним, почти то же самое можно сделать с помощью flock(1),
Тогда ещё будут висеть лишние pdeath_excute...

-- 
Regards,
Sir Raorn.

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

Re: [devel] /var/lock/rpm/update-vimhelp

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [080708 03:32]:
> Хотя в таком простом варианте есть race.
В моём варианте кажется тоже есть race...

As well as being removed by an explicit F_UNLCK, record locks are
automatically released when the process terminates or if it
closes any file descriptor referring to a file on which locks are
held. This is bad: it means that a process can lose the locks on
a file like /etc/passwd or /etc/mtab when for some reason a
library function decides to open, read and close it.

Или к другим процессам, которые открывают файл, это не относится?

-- 
Regards,
Sir Raorn.

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

Re: [devel] /var/lock/rpm/update-vimhelp

[Dmitry V. Levin]

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

On Tue, Jul 08, 2008 at 02:47:32PM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [080708 03:32]:
> > Хотя в таком простом варианте есть race.
> В моём варианте кажется тоже есть race...
> 
> As well as being removed by an explicit F_UNLCK, record locks are
> automatically released when the process terminates or if it
> closes any file descriptor referring to a file on which locks are
> held. This is bad: it means that a process can lose the locks on
> a file like /etc/passwd or /etc/mtab when for some reason a
> library function decides to open, read and close it.
> 
> Или к другим процессам, которые открывают файл, это не относится?

Конечно.


-- 
ldv

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

Re: [devel] repocop на sisyphus.ru [qualified]

[Yuri N. Sedunov]

В Пнд, 07/07/2008 в 23:06 +0400, Yuri N. Sedunov пишет:
> В Втр, 08/07/2008 в 01:33 +0700, Mikhail Gusarov пишет:
> > Twas brillig at 22:27:09 07.07.2008 UTC+04 when ldv@altlinux.org did gyre and gimble:
> > 
> <skip>
> > 
> > Аналогично, проблема с отсутствующим update_desktopdb должна быть решена
> > системно: одним (!) макросом для postinst/prerm, который занимается
> > менеджментом .desktop-файлов: как mime-entries, так и menu, причём
> > самостоятельно, а не напрягая мозг майнтайнера.
> 
> +100, может лучше даже начать с %post{,un}_ldconfig

Здесь ключевое слово -- СИСТЕМНО. Браво, Михаил Гусаров!
Как минимум, следующие конструкции должны быть удалены и "не напрягать мозг мантейнера". Список расширяем. 
Разумеется, должны быть учтены и УПОРЯДОЧЕНЫ все зависимости типа BuildPreReq, BuildRequires(pre)

%post
%post_ldconfig
%update_scrollkeeper
%update_desktopdb
%update_menus

%postun
%postun_ldconfig
%clean_scrollkeeper
%clean_desktopdb
%clean_menus


> 
> Yuri N. Sedunov

Re: [devel] /var/lock/rpm/update-vimhelp

[Dmitry V. Levin]

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

On Tue, Jul 08, 2008 at 04:24:46PM +0400, Dmitry V. Levin wrote:
> On Tue, Jul 08, 2008 at 02:47:32PM +0400, Alexey I. Froloff wrote:
> > * Dmitry V. Levin <ldv@> [080708 03:32]:
> > > Хотя в таком простом варианте есть race.
> > В моём варианте кажется тоже есть race...
> > 
> > As well as being removed by an explicit F_UNLCK, record locks are
> > automatically released when the process terminates or if it
> > closes any file descriptor referring to a file on which locks are
> > held. This is bad: it means that a process can lose the locks on
> > a file like /etc/passwd or /etc/mtab when for some reason a
> > library function decides to open, read and close it.
> > 
> > Или к другим процессам, которые открывают файл, это не относится?
> 
> Конечно.

Я понял, о чём ты спрашиваешь. ;)
Если parent сделал open, а потом fork,
child выполнил F_SETLK, а parent потом завершился,
то блокировка слетит в момент завершения parent.

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


-- 
ldv

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

Re: [devel] /var/lock/rpm/update-vimhelp

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [080709 01:34]:
> Я понял, о чём ты спрашиваешь. ;)
Не, я спрашивал про совсем другие процессы.  Второй
pdeath_execute открыл файл, обломался получить блокировку и
завершился.

> Если parent сделал open, а потом fork,
> child выполнил F_SETLK, а parent потом завершился,
> то блокировка слетит в момент завершения parent.
Какова вероятность, что при возврате из daemon() parent ещё не
умер?

> Другими словами, твой код работать в нынешнем виде не будет.
Ну а идея-то имеет право на существование?

-- 
Regards,
Sir Raorn.

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

Re: [devel] /var/lock/rpm/update-vimhelp

[Dmitry V. Levin]

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

On Wed, Jul 09, 2008 at 01:56:17AM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [080709 01:34]:
> > Я понял, о чём ты спрашиваешь. ;)
> Не, я спрашивал про совсем другие процессы.  Второй
> pdeath_execute открыл файл, обломался получить блокировку и
> завершился.

Этого можно не опасаться.

> > Если parent сделал open, а потом fork,
> > child выполнил F_SETLK, а parent потом завершился,
> > то блокировка слетит в момент завершения parent.
> Какова вероятность, что при возврате из daemon() parent ещё не
> умер?

Около 50%

> > Другими словами, твой код работать в нынешнем виде не будет.
> Ну а идея-то имеет право на существование?

Да, конечно.


-- 
ldv

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

Re: [devel] /var/lock/rpm/update-vimhelp

[Alexey Gladkov]

Dmitry V. Levin wrote:
>> Какова вероятность, что при возврате из daemon() parent ещё не
>> умер?
> 
> Около 50%

Либо встретишь динозавра, либо нет.

-- 
Rgrds, legion

Re: [devel] /var/lock/rpm/update-vimhelp

[Dmitry V. Levin]

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

On Wed, Jul 09, 2008 at 02:26:02AM +0400, Alexey Gladkov wrote:
> Dmitry V. Levin wrote:
> >>Какова вероятность, что при возврате из daemon() parent ещё не
> >>умер?
> >
> >Около 50%
> 
> Либо встретишь динозавра, либо нет.

Либо ты встретишь динозавра, либо он тебя. ;)


-- 
ldv

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

Re: [devel] /var/lock/rpm/update-vimhelp

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [080709 02:03]:
> > > Если parent сделал open, а потом fork, child выполнил
> > > F_SETLK, а parent потом завершился, то блокировка слетит в
> > > момент завершения parent.
> > Какова вероятность, что при возврате из daemon() parent ещё не
> > умер?
> Около 50%
Какое унылое [censored] эта GNU/RaceOS...

Если унести open() после daemon(), неудачное открытие файла
немного намусорит в консоль.  Ещё один race между close() и
execvp(), кто-то может туда просочиться.  Если close() не делать,
этот fd уйдёт в "тот процесс".  А mandatory locks можно сказать
что не работают.

Можно пойти сложным путём, делать open() и fcntl() до вызова
daemon(), потом делать ещё один fcntl(F_SETLKW) чтобы дождаться
смерти parent'а.  Или вызывать wait_for_pdeath() с pid'ом
parent'а, но это мне нравится ещё меньше.

Закоммитил первый вариант с мусором и утечкой дескриптора.

-- 
Regards,
Sir Raorn.

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