[devel] rpm: symlink to dir

[devel] rpm: symlink to dir

[Alexey Shabalin]

День добрый.
Есть ли текущая актуальная инструкция как при нашем новом rpm перейти
в пакете с симлинка на директорию?
Например, мне очень не нравится как упакован unbound.
В нем /etc/unbound -> ../var/lib/unbound/
Я конечно понимаю, что сделано по аналогии с bind, но и в bind мне эта
схема тоже не нравится.
Я хочу реально держать конфиги в /etc, где они попадут под контроль etckeeper.
Изменяемые данные в /var. Не правильно помечать как %config файлы в /var.
Если сервис запускается в chroot, то правильно скопировать нужные
файлы ему в chroot, а не делать такие хитрые симлинки.

Я готов заняться пакетом unbound, но останавливает то, что наш rpm не
умеет переезжать с симлинка на директорию.

-- 
Alexey Shabalin

Re: [devel] rpm: symlink to dir

[Dmitry V. Levin]

On Wed, Mar 18, 2020 at 04:05:02PM +0300, Alexey Shabalin wrote:
[...]
> Если сервис запускается в chroot, то правильно скопировать нужные
> файлы ему в chroot, а не делать такие хитрые симлинки.

Почему это?


-- 
ldv

Re: [devel] rpm: symlink to dir

[Alexey Shabalin]

ср, 18 мар. 2020 г. в 18:08, Dmitry V. Levin <ldv@altlinux.org>:
>
> On Wed, Mar 18, 2020 at 04:05:02PM +0300, Alexey Shabalin wrote:
> [...]
> > Если сервис запускается в chroot, то правильно скопировать нужные
> > файлы ему в chroot, а не делать такие хитрые симлинки.
>
> Почему это?

вопрос был не про это, но попробую описать минусы:
- для кофигов /etc, и можно помечать как %config(noreplace)
- в /var %config быть не должно - ваша же сборочница на это ругается
- etckeeper не видит конфигов в /var
- взлом сервиса в chroot может привести к порче или потере
конфигурационного файла. Если оригинал будет в /etc, то при
перезапуске сервиса мы просто восстанавливаем конфиг из оригинала. А
если сервис умеет сначала читать конфиг а потом чрутиться, то и конфиг
в chroot не нужен(имея симлинк мы связаны по рукам и ничего сделать не
можем).


-- 
Alexey Shabalin

Re: [devel] rpm: symlink to dir

[Denis Medvedev]

On 3/18/20 7:46 PM, Alexey Shabalin wrote:
> ср, 18 мар. 2020 г. в 18:08, Dmitry V. Levin <ldv@altlinux.org>:
>> On Wed, Mar 18, 2020 at 04:05:02PM +0300, Alexey Shabalin wrote:
>> [...]
>>> Если сервис запускается в chroot, то правильно скопировать нужные
>>> файлы ему в chroot, а не делать такие хитрые симлинки.
>> Почему это?
> вопрос был не про это, но попробую описать минусы:
> - для кофигов /etc, и можно помечать как %config(noreplace)
> - в /var %config быть не должно - ваша же сборочница на это ругается
> - etckeeper не видит конфигов в /var
> - взлом сервиса в chroot может привести к порче или потере
> конфигурационного файла. Если оригинал будет в /etc, то при
> перезапуске сервиса мы просто восстанавливаем конфиг из оригинала. А
> если сервис умеет сначала читать конфиг а потом чрутиться, то и конфиг
> в chroot не нужен(имея симлинк мы связаны по рукам и ничего сделать не
> можем).

Ух а это аргумент и против хардлинкинга в chroot-ах вообще!

Может уберем?


>
>

Re: [devel] rpm: symlink to dir

[Vladimir D. Seleznev]

On Wed, Mar 18, 2020 at 07:51:39PM +0300, Denis Medvedev wrote:
> On 3/18/20 7:46 PM, Alexey Shabalin wrote:
> > ср, 18 мар. 2020 г. в 18:08, Dmitry V. Levin <ldv@altlinux.org>:
> >> On Wed, Mar 18, 2020 at 04:05:02PM +0300, Alexey Shabalin wrote:
> >> [...]
> >>> Если сервис запускается в chroot, то правильно скопировать нужные
> >>> файлы ему в chroot, а не делать такие хитрые симлинки.
> >> Почему это?
> > вопрос был не про это, но попробую описать минусы:
> > - для кофигов /etc, и можно помечать как %config(noreplace)
> > - в /var %config быть не должно - ваша же сборочница на это ругается
> > - etckeeper не видит конфигов в /var
> > - взлом сервиса в chroot может привести к порче или потере
> > конфигурационного файла. Если оригинал будет в /etc, то при
> > перезапуске сервиса мы просто восстанавливаем конфиг из оригинала. А
> > если сервис умеет сначала читать конфиг а потом чрутиться, то и конфиг
> > в chroot не нужен(имея симлинк мы связаны по рукам и ничего сделать не
> > можем).
> 
> Ух а это аргумент и против хардлинкинга в chroot-ах вообще!

Хардлинков и так не используются, более того, их нельзя использовать,
т.к. /etc/ и /var/ могут находиться на разных файловых системах.

> Может уберем?

Наверное, всё же имелся в виду симлинк.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] rpm: symlink to dir

[Ivan Zakharyaschev]

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


On Wed, 18 Mar 2020, Vladimir D. Seleznev wrote:

> On Wed, Mar 18, 2020 at 07:51:39PM +0300, Denis Medvedev wrote:
> > On 3/18/20 7:46 PM, Alexey Shabalin wrote:
> > > ср, 18 мар. 2020 г. в 18:08, Dmitry V. Levin <ldv@altlinux.org>:
> > >> On Wed, Mar 18, 2020 at 04:05:02PM +0300, Alexey Shabalin wrote:
> > >> [...]
> > >>> Если сервис запускается в chroot, то правильно скопировать нужные
> > >>> файлы ему в chroot, а не делать такие хитрые симлинки.
> > >> Почему это?
> > > вопрос был не про это, но попробую описать минусы:
> > > - для кофигов /etc, и можно помечать как %config(noreplace)
> > > - в /var %config быть не должно - ваша же сборочница на это ругается
> > > - etckeeper не видит конфигов в /var
> > > - взлом сервиса в chroot может привести к порче или потере
> > > конфигурационного файла. Если оригинал будет в /etc, то при
> > > перезапуске сервиса мы просто восстанавливаем конфиг из оригинала. А
> > > если сервис умеет сначала читать конфиг а потом чрутиться, то и конфиг
> > > в chroot не нужен(имея симлинк мы связаны по рукам и ничего сделать не
> > > можем).
> > 
> > Ух а это аргумент и против хардлинкинга в chroot-ах вообще!
> 
> Хардлинков и так не используются, более того, их нельзя использовать,
> т.к. /etc/ и /var/ могут находиться на разных файловых системах.

Смотря какие файлы ты имешь в виду, ты либо прав, либо нет.

Есть файлы, которые hardlink-аются в chroot, но не те, которые здесь 
обсуждались сначала.

/var/ на другом разделе не проблема для этого алгоритма (который делает 
ln в функции Copy() в chrooted), потому что в случае неудачи ln, он делает 
cp или install.

> > Может уберем?
> 
> Наверное, всё же имелся в виду симлинк.


-- 
Best regards,
Ivan

Re: [devel] rpm: symlink to dir

[Vladimir D. Seleznev]

On Wed, Mar 18, 2020 at 08:21:55PM +0300, Ivan Zakharyaschev wrote:
> 
> On Wed, 18 Mar 2020, Vladimir D. Seleznev wrote:
> 
> > On Wed, Mar 18, 2020 at 07:51:39PM +0300, Denis Medvedev wrote:
> > > On 3/18/20 7:46 PM, Alexey Shabalin wrote:
> > > > ср, 18 мар. 2020 г. в 18:08, Dmitry V. Levin <ldv@altlinux.org>:
> > > >> On Wed, Mar 18, 2020 at 04:05:02PM +0300, Alexey Shabalin wrote:
> > > >> [...]
> > > >>> Если сервис запускается в chroot, то правильно скопировать нужные
> > > >>> файлы ему в chroot, а не делать такие хитрые симлинки.
> > > >> Почему это?
> > > > вопрос был не про это, но попробую описать минусы:
> > > > - для кофигов /etc, и можно помечать как %config(noreplace)
> > > > - в /var %config быть не должно - ваша же сборочница на это ругается
> > > > - etckeeper не видит конфигов в /var
> > > > - взлом сервиса в chroot может привести к порче или потере
> > > > конфигурационного файла. Если оригинал будет в /etc, то при
> > > > перезапуске сервиса мы просто восстанавливаем конфиг из оригинала. А
> > > > если сервис умеет сначала читать конфиг а потом чрутиться, то и конфиг
> > > > в chroot не нужен(имея симлинк мы связаны по рукам и ничего сделать не
> > > > можем).
> > > 
> > > Ух а это аргумент и против хардлинкинга в chroot-ах вообще!
> > 
> > Хардлинков и так не используются, более того, их нельзя использовать,
> > т.к. /etc/ и /var/ могут находиться на разных файловых системах.
> 
> Смотря какие файлы ты имешь в виду, ты либо прав, либо нет.
> 
> Есть файлы, которые hardlink-аются в chroot, но не те, которые здесь 
> обсуждались сначала.
> 
> /var/ на другом разделе не проблема для этого алгоритма (который делает 
> ln в функции Copy() в chrooted), потому что в случае неудачи ln, он делает 
> cp или install.

А, OK.

-- 
   С уважением,
   Владимир Селезнев

Re: [devel] rpm: symlink to dir

[Alexey V. Vissarionov]

On 2020-03-18 20:21:55 +0300, Ivan Zakharyaschev wrote:

 >>> Ух а это аргумент и против хардлинкинга в chroot-ах вообще!
 >> Хардлинков и так не используются, более того, их нельзя
 >> использовать, т.к. /etc/ и /var/ могут находиться на разных
 >> файловых системах.

А могут и не находиться. Что в общем-то вполне разумно: нехрен за
админа думать - все равно не угадаешь, что ему нужно.

 > Смотря какие файлы ты имешь в виду, ты либо прав, либо нет. Есть
 > файлы, которые hardlink-аются в chroot, но не те, которые здесь
 > обсуждались сначала.
 > /var/ на другом разделе не проблема для этого алгоритма (который
 > делает ln в функции Copy() в chrooted), потому что в случае
 > неудачи ln, он делает cp или install.

А вот это хоть и не самое expected behaviour, но уже хорошо: хочешь
сделать по уму - смонтируй /var как отдельную ФС.

На десктопной системе это, разумеется, всем пофигу, но не десктопом
единым.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rpm: symlink to dir

[Alexey Shabalin]

ср, 18 мар. 2020 г. в 20:01, Vladimir D. Seleznev <vseleznv@altlinux.org>:
>
> On Wed, Mar 18, 2020 at 07:51:39PM +0300, Denis Medvedev wrote:
> > On 3/18/20 7:46 PM, Alexey Shabalin wrote:
> > > ср, 18 мар. 2020 г. в 18:08, Dmitry V. Levin <ldv@altlinux.org>:
> > >> On Wed, Mar 18, 2020 at 04:05:02PM +0300, Alexey Shabalin wrote:
> > >> [...]
> > >>> Если сервис запускается в chroot, то правильно скопировать нужные
> > >>> файлы ему в chroot, а не делать такие хитрые симлинки.
> > >> Почему это?
> > > вопрос был не про это, но попробую описать минусы:
> > > - для кофигов /etc, и можно помечать как %config(noreplace)
> > > - в /var %config быть не должно - ваша же сборочница на это ругается
> > > - etckeeper не видит конфигов в /var
> > > - взлом сервиса в chroot может привести к порче или потере
> > > конфигурационного файла. Если оригинал будет в /etc, то при
> > > перезапуске сервиса мы просто восстанавливаем конфиг из оригинала. А
> > > если сервис умеет сначала читать конфиг а потом чрутиться, то и конфиг
> > > в chroot не нужен(имея симлинк мы связаны по рукам и ничего сделать не
> > > можем).
> >
> > Ух а это аргумент и против хардлинкинга в chroot-ах вообще!
>
> Хардлинков и так не используются, более того, их нельзя использовать,
> т.к. /etc/ и /var/ могут находиться на разных файловых системах.

Ты ошибаешься, наш chrooted предпочитает делать хардлинки, и если не
получилось, то копирует.

>
> > Может уберем?

Ты же говорил, что в сертифицированных дистрибутивах для selinux тебе
это мешает и вы убираете? И вроде собирались переносить наработки в
сизиф?

PS: пожалуйста начинайте новые темы, если текущая тема отличается.
Я прошу дать мне инструмент миграции symlink -> dir в rpm.
Пока что все пытаются уйти от вопроса придумывая новые :)

-- 
Alexey Shabalin

Re: [devel] rpm: symlink to dir

[Anton Farygin]

On 18.03.2020 20:28, Alexey Shabalin wrote:
> Я прошу дать мне инструмент миграции symlink -> dir в rpm.
> Пока что все пытаются уйти от вопроса придумывая новые:)

Ну если за несколько лет не придумали, то скорее всего и сейчас не 
придумают.

Нужно обновлять rpmbuild (или тащить из апстрима изменения к нам).

Тогда, вероятно, появится инструмент.

Re: [devel] rpm: symlink to dir

[Ivan Zakharyaschev]

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

On Wed, 18 Mar 2020, Denis Medvedev wrote:

> On 3/18/20 7:46 PM, Alexey Shabalin wrote:
> > ср, 18 мар. 2020 г. в 18:08, Dmitry V. Levin <ldv@altlinux.org>:
> > > On Wed, Mar 18, 2020 at 04:05:02PM +0300, Alexey Shabalin wrote:
> > > [...]
> > > > Если сервис запускается в chroot, то правильно скопировать нужные
> > > > файлы ему в chroot, а не делать такие хитрые симлинки.
> > > Почему это?
> > вопрос был не про это, но попробую описать минусы:
> > - для кофигов /etc, и можно помечать как %config(noreplace)
> > - в /var %config быть не должно - ваша же сборочница на это ругается
> > - etckeeper не видит конфигов в /var
> > - взлом сервиса в chroot может привести к порче или потере
> > конфигурационного файла. Если оригинал будет в /etc, то при
> > перезапуске сервиса мы просто восстанавливаем конфиг из оригинала. А
> > если сервис умеет сначала читать конфиг а потом чрутиться, то и конфиг
> > в chroot не нужен(имея симлинк мы связаны по рукам и ничего сделать не
> > можем).
> 
> Ух а это аргумент и против хардлинкинга в chroot-ах вообще!

Но если он стал root-ом в chroot-е, то он и так может легко выбраться, 
разве нет?

Или не легко?

Поэтому с этой точки зрения нет никакой разницы (если файлы принадлежат 
root-у), hardlink-и это или файлы которые кто-то читает по симлинкам 
снаружи. (Но подчёркиваю: при условии, если они принадлежат root-у или 
другому пользователю, от имени которого никакие сервисы не работают.)

-- 
Best regards,
Ivan

Re: [devel] rpm: symlink to dir

[Dmitry V. Levin]

On Wed, Mar 18, 2020 at 08:19:35PM +0300, Ivan Zakharyaschev wrote:
[...]
> Но если он стал root-ом в chroot-е, то он и так может легко выбраться, 
> разве нет?
> 
> Или не легко?

chdir("/");
chroot("etc");
chdir("../../../../../../../..");
chroot(".");
- это достаточно легко?


-- 
ldv

Re: [devel] rpm: symlink to dir

[Alexey V. Vissarionov]

On 2020-03-18 19:51:39 +0300, Denis Medvedev wrote:
 >>>> Если сервис запускается в chroot, то правильно скопировать
 >>>> нужные файлы ему в chroot, а не делать такие хитрые симлинки.
 >>> Почему это?
 >> - взлом сервиса в chroot может привести к порче или потере
 >> конфигурационного файла. Если оригинал будет в /etc, то при
 >> перезапуске сервиса мы просто восстанавливаем конфиг из
 >> оригинала. А если сервис умеет сначала читать конфиг а потом
 >> чрутиться, то и конфиг в chroot не нужен(имея симлинк мы
 >> связаны по рукам и ничего сделать не можем).
 > Ух а это аргумент и против хардлинкинга в chroot-ах вообще!
 > Может уберем?

Очень боюсь сболтнуть Страшную Админскую Тайну, но все же: /var
можно разместить на отдельной файловой системе - заодно ее можно
будет монтировать с noexec,nodev,noatime

А держать в /var что-то важное - то самое кроилово, которое рано
или поздно приводит к попадалову. Общее правило: /var не подлежит
регулярному резервному копированию.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rpm: symlink to dir

[Denis Medvedev]

On 3/18/20 9:32 PM, Alexey V. Vissarionov wrote:
> On 2020-03-18 19:51:39 +0300, Denis Medvedev wrote:
>   >>>> Если сервис запускается в chroot, то правильно скопировать
>   >>>> нужные файлы ему в chroot, а не делать такие хитрые симлинки.
>   >>> Почему это?
>   >> - взлом сервиса в chroot может привести к порче или потере
>   >> конфигурационного файла. Если оригинал будет в /etc, то при
>   >> перезапуске сервиса мы просто восстанавливаем конфиг из
>   >> оригинала. А если сервис умеет сначала читать конфиг а потом
>   >> чрутиться, то и конфиг в chroot не нужен(имея симлинк мы
>   >> связаны по рукам и ничего сделать не можем).
>   > Ух а это аргумент и против хардлинкинга в chroot-ах вообще!
>   > Может уберем?
>
> Очень боюсь сболтнуть Страшную Админскую Тайну, но все же: /var
> можно разместить на отдельной файловой системе - заодно ее можно
> будет монтировать с noexec,nodev,noatime
>
> А держать в /var что-то важное - то самое кроилово, которое рано
> или поздно приводит к попадалову. Общее правило: /var не подлежит
> регулярному резервному копированию.
>
И поэтому тоже - я бы хотел иметь опцию работать вообще без chrootеd 
iservices.

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

администрирование, вводя еще одно место где могут разъехаться данные.

Re: [devel] rpm: symlink to dir

[Anton V. Boyarshinov]

On Wed, 18 Mar 2020 21:32:00 +0300 Alexey V. Vissarionov wrote:

>  Общее правило: /var не подлежит
> регулярному резервному копированию.

То, что для некоторых необычных людей что-то является общим правилом,
не делает это общим правилом для всех людей.

Я знаю не мало серверов, на которых всё ценное находится именно в /var
и на них это единственная fs, которая стоит резервного копирования. И
не вижу необходимости всё переделывать ради "авторитетного" мнения,
что /var недостоин.

Re: [devel] rpm: symlink to dir

[Alexey V. Vissarionov]

On 2020-03-19 11:54:46 +0300, Anton V. Boyarshinov wrote:

 >> Общее правило: /var не подлежит регулярному резервному копированию.
 > То, что для некоторых необычных людей что-то является общим
 > правилом, не делает это общим правилом для всех людей.

`man hier`

 > Я знаю не мало серверов, на которых всё ценное находится
 > именно в /var и на них это единственная fs, которая стоит
 > резервного копирования. И не вижу необходимости всё
 > переделывать ради "авторитетного" мнения, что /var недостоин.

Как говорили древние латиняне, quisque masturbatum ad voluntatem.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rpm: symlink to dir

[Anton V. Boyarshinov]

On Thu, 19 Mar 2020 12:09:10 +0300 Alexey V. Vissarionov wrote:

>  >> Общее правило: /var не подлежит регулярному резервному копированию.  
>  > То, что для некоторых необычных людей что-то является общим
>  > правилом, не делает это общим правилом для всех людей.  
> 
> `man hier`

Не нахожу в нём подтверждений твоим словам и противоречия с моими.

Re: [devel] rpm: symlink to dir

[Sergey Afonin]

On Wednesday 18 March 2020, Alexey V. Vissarionov wrote:

> А держать в /var что-то важное - то самое кроилово, которое рано
> или поздно приводит к попадалову. Общее правило: /var не подлежит
> регулярному резервному копированию.

А как же всякие /var/lib/mysql/db и /var/spool/imap? Так-то конечно
их надо на отдельные ФС убирать, но если отдельных ФС не сделать, то
это /var.

-- 
С уважением, Сергей Афонин.

Re: [devel] rpm: symlink to dir

[Andrey Savchenko]

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

On Wed, 18 Mar 2020 16:05:02 +0300 Alexey Shabalin wrote:
> День добрый.
> Есть ли текущая актуальная инструкция как при нашем новом rpm перейти
> в пакете с симлинка на директорию?
> Например, мне очень не нравится как упакован unbound.
> В нем /etc/unbound -> ../var/lib/unbound/
> Я конечно понимаю, что сделано по аналогии с bind, но и в bind мне эта
> схема тоже не нравится.
> Я хочу реально держать конфиги в /etc, где они попадут под контроль etckeeper.
> Изменяемые данные в /var. Не правильно помечать как %config файлы в /var.
> Если сервис запускается в chroot, то правильно скопировать нужные
> файлы ему в chroot, а не делать такие хитрые симлинки.
> 
> Я готов заняться пакетом unbound, но останавливает то, что наш rpm не
> умеет переезжать с симлинка на директорию.

Да никакой не умеет, это фундаментальное ограничение rpm
Но в Федоре используют хак с %pretrans:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/#_scriptlet_to_replace_a_symlink_to_a_directory_with_a_directory

Возможно, у нас можно что-то аналогичное в %pre сделать;
но, скорее всего, нужно добавлять в rpm поддержку именно %pretrans.

Best regards,
Andrew Savchenko

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

Re: [devel] rpm: symlink to dir

[Alexey Shabalin]

ср, 18 мар. 2020 г. в 22:53, Andrey Savchenko <bircoph@altlinux.org>:
>
> On Wed, 18 Mar 2020 16:05:02 +0300 Alexey Shabalin wrote:
> > День добрый.
> > Есть ли текущая актуальная инструкция как при нашем новом rpm перейти
> > в пакете с симлинка на директорию?
> > Например, мне очень не нравится как упакован unbound.
> > В нем /etc/unbound -> ../var/lib/unbound/
> > Я конечно понимаю, что сделано по аналогии с bind, но и в bind мне эта
> > схема тоже не нравится.
> > Я хочу реально держать конфиги в /etc, где они попадут под контроль etckeeper.
> > Изменяемые данные в /var. Не правильно помечать как %config файлы в /var.
> > Если сервис запускается в chroot, то правильно скопировать нужные
> > файлы ему в chroot, а не делать такие хитрые симлинки.
> >
> > Я готов заняться пакетом unbound, но останавливает то, что наш rpm не
> > умеет переезжать с симлинка на директорию.
>
> Да никакой не умеет, это фундаментальное ограничение rpm
> Но в Федоре используют хак с %pretrans:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/#_scriptlet_to_replace_a_symlink_to_a_directory_with_a_directory
>
> Возможно, у нас можно что-то аналогичное в %pre сделать;
> но, скорее всего, нужно добавлять в rpm поддержку именно %pretrans.

В том-то и дело, что со старым rpm был объезд, а с новым старый трюк
не работает.
И нового варианта никто не предлагает. А он нужен!


-- 
Alexey Shabalin

Re: [devel] rpm: symlink to dir

[Ivan A. Melnikov]

On Wed, Mar 18, 2020 at 04:05:02PM +0300, Alexey Shabalin wrote:
> День добрый.
> Есть ли текущая актуальная инструкция как при нашем новом rpm перейти
> в пакете с симлинка на директорию?
> Например, мне очень не нравится как упакован unbound.
> В нем /etc/unbound -> ../var/lib/unbound/
> Я конечно понимаю, что сделано по аналогии с bind, но и в bind мне эта
> схема тоже не нравится.
> Я хочу реально держать конфиги в /etc, где они попадут под контроль etckeeper.
> Изменяемые данные в /var. Не правильно помечать как %config файлы в /var.
> Если сервис запускается в chroot, то правильно скопировать нужные
> файлы ему в chroot, а не делать такие хитрые симлинки.
> 
> Я готов заняться пакетом unbound, но останавливает то, что наш rpm не
> умеет переезжать с симлинка на директорию.

https://bugzilla.altlinux.org/show_bug.cgi?id=34619

Насколько я знаю, с тех пор ничего не изменилось.

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

-- 
  wbr,
    iv m.

Re: [devel] rpm: symlink to dir

[Anton Farygin]

On 19.03.2020 10:33, Ivan A. Melnikov wrote:
> On Wed, Mar 18, 2020 at 04:05:02PM +0300, Alexey Shabalin wrote:
>> День добрый.
>> Есть ли текущая актуальная инструкция как при нашем новом rpm перейти
>> в пакете с симлинка на директорию?
>> Например, мне очень не нравится как упакован unbound.
>> В нем /etc/unbound -> ../var/lib/unbound/
>> Я конечно понимаю, что сделано по аналогии с bind, но и в bind мне эта
>> схема тоже не нравится.
>> Я хочу реально держать конфиги в /etc, где они попадут под контроль etckeeper.
>> Изменяемые данные в /var. Не правильно помечать как %config файлы в /var.
>> Если сервис запускается в chroot, то правильно скопировать нужные
>> файлы ему в chroot, а не делать такие хитрые симлинки.
>>
>> Я готов заняться пакетом unbound, но останавливает то, что наш rpm не
>> умеет переезжать с симлинка на директорию.
> https://bugzilla.altlinux.org/show_bug.cgi?id=34619
>
> Насколько я знаю, с тех пор ничего не изменилось.
>
> У меня есть планы и желание этим заняться, если получится найти
> время на разработку до того, как кто-то другой уже всё сделает.

На других в данном вопросе у меня уже давно надежд нету.

Но было бы отлично услышать их мнение по этому поводу здесь.

Re: [devel] rpm: symlink to dir

[Alexey Shabalin]

ср, 18 мар. 2020 г. в 16:05, Alexey Shabalin <a.shabalin@gmail.com>:
>
> День добрый.
> Есть ли текущая актуальная инструкция как при нашем новом rpm перейти
> в пакете с симлинка на директорию?

День добрый.
Возник еще один пакет, где хотелось бы перейти с симлинка на каталог
на реальный каталог.
Появилась инструкция как это сделать?

-- 
Alexey Shabalin

Re: [devel] rpm: symlink to dir

[Alexey V. Vissarionov]

On 2020-12-27 17:57:05 +0300, Alexey Shabalin wrote:

 >> Есть ли текущая актуальная инструкция как при нашем новом
 >> rpm перейти в пакете с симлинка на директорию?
 > День добрый. Возник еще один пакет, где хотелось бы перейти с
 > симлинка на каталог на реальный каталог. Появилась инструкция
 > как это сделать?

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

Использовать этот способ для дистрибутива, наверное, лучше не надо.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rpm: symlink to dir

[Leonid Krivoshein]

27.12.2020 18:48, Alexey V. Vissarionov пишет:
> On 2020-12-27 17:57:05 +0300, Alexey Shabalin wrote:
>
>   >> Есть ли текущая актуальная инструкция как при нашем новом
>   >> rpm перейти в пакете с симлинка на директорию?
>   > День добрый. Возник еще один пакет, где хотелось бы перейти с
>   > симлинка на каталог на реальный каталог. Появилась инструкция
>   > как это сделать?
>
> Насколько я понимаю, инструкции не было (я бы ее вряд ли пропустил).
> Безболезненный переход, по-моему, в принципе невозможен, а снизить
> ущерб мне удавалось только совсем очевидным (и столь же колхозным)
> способом с временным пакетом и переносом файлов в два этапа (у меня
> это были конфиги, так что размер не напрягал), но после этого в ОС
> оставался мусор в виде файлов, не охваченных пакетной системой.
>
> Использовать этот способ для дистрибутива, наверное, лучше не надо.

Предложил бы для всех подобных симлинков (каталогов):

- использовать специальный файл в корне со списком путей, подлежащих 
замене типа (например, /.rpmlinks);
- замена должна производиться в initrd (stage1) при первой же 
перезагрузке, пока никто там ничего не использует;
- от rpm требуется обработка такой ситуации и "понимание" временно 
непригодного состояния (до перезагрузки).

Т.е., мне кажется, если реализовать поддержку одновременно и в rpm, и в 
make-initrd, должно получиться относительно безболезненно.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] rpm: symlink to dir

[Andrey Savchenko]

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

On Mon, 28 Dec 2020 01:51:24 +0300 Leonid Krivoshein wrote:
> 
> 27.12.2020 18:48, Alexey V. Vissarionov пишет:
> > On 2020-12-27 17:57:05 +0300, Alexey Shabalin wrote:
> >
> >   >> Есть ли текущая актуальная инструкция как при нашем новом
> >   >> rpm перейти в пакете с симлинка на директорию?
> >   > День добрый. Возник еще один пакет, где хотелось бы перейти с
> >   > симлинка на каталог на реальный каталог. Появилась инструкция
> >   > как это сделать?
> >
> > Насколько я понимаю, инструкции не было (я бы ее вряд ли пропустил).
> > Безболезненный переход, по-моему, в принципе невозможен, а снизить
> > ущерб мне удавалось только совсем очевидным (и столь же колхозным)
> > способом с временным пакетом и переносом файлов в два этапа (у меня
> > это были конфиги, так что размер не напрягал), но после этого в ОС
> > оставался мусор в виде файлов, не охваченных пакетной системой.
> >
> > Использовать этот способ для дистрибутива, наверное, лучше не надо.
> 
> Предложил бы для всех подобных симлинков (каталогов):
> 
> - использовать специальный файл в корне со списком путей, подлежащих 
> замене типа (например, /.rpmlinks);
> - замена должна производиться в initrd (stage1) при первой же 
> перезагрузке, пока никто там ничего не использует;
> - от rpm требуется обработка такой ситуации и "понимание" временно 
> непригодного состояния (до перезагрузки).
> 
> Т.е., мне кажется, если реализовать поддержку одновременно и в rpm, и в 
> make-initrd, должно получиться относительно безболезненно.

Проблема решается кардинально просто, но на уровне rpm: следует
отказаться от концепции владельца директории и сохранять только
владельцев файлов. Тогда что симлинк, что директория — разницы для
PM никакой не будет. А удаляться они будут только если пустые. Ну
если очень нужно пустую директорию установить, то можно в неё
положить файлик '.keepdir'.

Best regards,
Andrew Savchenko

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

Re: [devel] rpm: symlink to dir

[Mikhail Novosyolov]

28.12.2020 02:08, Andrey Savchenko пишет:
> On Mon, 28 Dec 2020 01:51:24 +0300 Leonid Krivoshein wrote:
>> 27.12.2020 18:48, Alexey V. Vissarionov пишет:
>>> On 2020-12-27 17:57:05 +0300, Alexey Shabalin wrote:
>>>
>>>   >> Есть ли текущая актуальная инструкция как при нашем новом
>>>   >> rpm перейти в пакете с симлинка на директорию?
>>>   > День добрый. Возник еще один пакет, где хотелось бы перейти с
>>>   > симлинка на каталог на реальный каталог. Появилась инструкция
>>>   > как это сделать?
>>>
>>> Насколько я понимаю, инструкции не было (я бы ее вряд ли пропустил).
>>> Безболезненный переход, по-моему, в принципе невозможен, а снизить
>>> ущерб мне удавалось только совсем очевидным (и столь же колхозным)
>>> способом с временным пакетом и переносом файлов в два этапа (у меня
>>> это были конфиги, так что размер не напрягал), но после этого в ОС
>>> оставался мусор в виде файлов, не охваченных пакетной системой.
>>>
>>> Использовать этот способ для дистрибутива, наверное, лучше не надо.
>> Предложил бы для всех подобных симлинков (каталогов):
>>
>> - использовать специальный файл в корне со списком путей, подлежащих 
>> замене типа (например, /.rpmlinks);
>> - замена должна производиться в initrd (stage1) при первой же 
>> перезагрузке, пока никто там ничего не использует;
>> - от rpm требуется обработка такой ситуации и "понимание" временно 
>> непригодного состояния (до перезагрузки).
>>
>> Т.е., мне кажется, если реализовать поддержку одновременно и в rpm, и в 
>> make-initrd, должно получиться относительно безболезненно.
> Проблема решается кардинально просто, но на уровне rpm: следует
> отказаться от концепции владельца директории и сохранять только
> владельцев файлов. Тогда что симлинк, что директория — разницы для
> PM никакой не будет. А удаляться они будут только если пустые. Ну
> если очень нужно пустую директорию установить, то можно в неё
> положить файлик '.keepdir'.

На уровне rpm давно придуман %pretrans на lua.

Отказаться от концепции владельца директории странная идея, существуют же заведомо пустые директории, кому они будут принадлежать?

Re: [devel] rpm: symlink to dir

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 02:17:23AM +0300, Mikhail Novosyolov wrote:
[...]
> На уровне rpm давно придуман %pretrans на lua.

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


-- 
ldv

Re: [devel] rpm: symlink to dir

[Andrey Savchenko]

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

On Mon, 28 Dec 2020 02:17:23 +0300 Mikhail Novosyolov wrote:
> 
> 28.12.2020 02:08, Andrey Savchenko пишет:
> > On Mon, 28 Dec 2020 01:51:24 +0300 Leonid Krivoshein wrote:
> >> 27.12.2020 18:48, Alexey V. Vissarionov пишет:
> >>> On 2020-12-27 17:57:05 +0300, Alexey Shabalin wrote:
> >>>
> >>>   >> Есть ли текущая актуальная инструкция как при нашем новом
> >>>   >> rpm перейти в пакете с симлинка на директорию?
> >>>   > День добрый. Возник еще один пакет, где хотелось бы перейти с
> >>>   > симлинка на каталог на реальный каталог. Появилась инструкция
> >>>   > как это сделать?
> >>>
> >>> Насколько я понимаю, инструкции не было (я бы ее вряд ли пропустил).
> >>> Безболезненный переход, по-моему, в принципе невозможен, а снизить
> >>> ущерб мне удавалось только совсем очевидным (и столь же колхозным)
> >>> способом с временным пакетом и переносом файлов в два этапа (у меня
> >>> это были конфиги, так что размер не напрягал), но после этого в ОС
> >>> оставался мусор в виде файлов, не охваченных пакетной системой.
> >>>
> >>> Использовать этот способ для дистрибутива, наверное, лучше не надо.
> >> Предложил бы для всех подобных симлинков (каталогов):
> >>
> >> - использовать специальный файл в корне со списком путей, подлежащих 
> >> замене типа (например, /.rpmlinks);
> >> - замена должна производиться в initrd (stage1) при первой же 
> >> перезагрузке, пока никто там ничего не использует;
> >> - от rpm требуется обработка такой ситуации и "понимание" временно 
> >> непригодного состояния (до перезагрузки).
> >>
> >> Т.е., мне кажется, если реализовать поддержку одновременно и в rpm, и в 
> >> make-initrd, должно получиться относительно безболезненно.
> > Проблема решается кардинально просто, но на уровне rpm: следует
> > отказаться от концепции владельца директории и сохранять только
> > владельцев файлов. Тогда что симлинк, что директория — разницы для
> > PM никакой не будет. А удаляться они будут только если пустые. Ну
> > если очень нужно пустую директорию установить, то можно в неё
> > положить файлик '.keepdir'.
> 
> На уровне rpm давно придуман %pretrans на lua.
> 
> Отказаться от концепции владельца директории странная идея, существуют же заведомо пустые директории, кому они будут принадлежать?

Тому, кому принадлежит скрытый файл .keepdir внутри таких
директорий.

Best regards,
Andrew Savchenko

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

Re: [devel] rpm: symlink to dir

[Andrey Savchenko]

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

On Mon, 28 Dec 2020 14:18:01 +0300 Denis Medvedev wrote:
> On 12/28/20 12:41 PM, Andrey Savchenko wrote:
> > On Mon, 28 Dec 2020 02:17:23 +0300 Mikhail Novosyolov wrote:
> >> 28.12.2020 02:08, Andrey Savchenko пишет:
> >>> On Mon, 28 Dec 2020 01:51:24 +0300 Leonid Krivoshein wrote:
> >>>> 27.12.2020 18:48, Alexey V. Vissarionov пишет:
> >>>>> On 2020-12-27 17:57:05 +0300, Alexey Shabalin wrote:
> >>>>>
> >>>>>    >> Есть ли текущая актуальная инструкция как при нашем новом
> >>>>>    >> rpm перейти в пакете с симлинка на директорию?
> >>>>>    > День добрый. Возник еще один пакет, где хотелось бы перейти с
> >>>>>    > симлинка на каталог на реальный каталог. Появилась инструкция
> >>>>>    > как это сделать?
> >>>>>
> >>>>> Насколько я понимаю, инструкции не было (я бы ее вряд ли пропустил).
> >>>>> Безболезненный переход, по-моему, в принципе невозможен, а снизить
> >>>>> ущерб мне удавалось только совсем очевидным (и столь же колхозным)
> >>>>> способом с временным пакетом и переносом файлов в два этапа (у меня
> >>>>> это были конфиги, так что размер не напрягал), но после этого в ОС
> >>>>> оставался мусор в виде файлов, не охваченных пакетной системой.
> >>>>>
> >>>>> Использовать этот способ для дистрибутива, наверное, лучше не надо.
> >>>> Предложил бы для всех подобных симлинков (каталогов):
> >>>>
> >>>> - использовать специальный файл в корне со списком путей, подлежащих
> >>>> замене типа (например, /.rpmlinks);
> >>>> - замена должна производиться в initrd (stage1) при первой же
> >>>> перезагрузке, пока никто там ничего не использует;
> >>>> - от rpm требуется обработка такой ситуации и "понимание" временно
> >>>> непригодного состояния (до перезагрузки).
> >>>>
> >>>> Т.е., мне кажется, если реализовать поддержку одновременно и в rpm, и в
> >>>> make-initrd, должно получиться относительно безболезненно.
> >>> Проблема решается кардинально просто, но на уровне rpm: следует
> >>> отказаться от концепции владельца директории и сохранять только
> >>> владельцев файлов. Тогда что симлинк, что директория — разницы для
> >>> PM никакой не будет. А удаляться они будут только если пустые. Ну
> >>> если очень нужно пустую директорию установить, то можно в неё
> >>> положить файлик '.keepdir'.
> >> На уровне rpm давно придуман %pretrans на lua.
> >>
> >> Отказаться от концепции владельца директории странная идея, существуют же заведомо пустые директории, кому они будут принадлежать?
> > Тому, кому принадлежит скрытый файл .keepdir внутри таких
> > директорий.
> 
> В таком случае такой каталог будет уже не пуст, некоторым программам 
> будут нужны совершенно пустые каталоги

Пример? По-моему, это чисто гипотетическая ситуация.
 
> А что будет, если туда положить %ghost файл .keepdir ? Будет ли такой 
> каталог считаться за программой?

Зависит от реализации. Можно как раз использовать для описанной
выше ситуации, когда нужен абсолютно пустой каталог.

Если честно, я не совсем понимаю, зачем вообще нужен %gost. Я знаю,
что он делает — позволяет закрепить несуществующий в пакете файл за
пакетом — но мне представляется, что это ошибочная концепция и её
использование говорит об ошибке в пакетировании пакета.

Best regards,
Andrew Savchenko

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

Re: [devel] rpm: symlink to dir

[Alexey V. Vissarionov]

On 2020-12-28 16:00:10 +0300, Andrey Savchenko wrote:

 > Если честно, я не совсем понимаю, зачем вообще нужен %gost.

%ghost

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

Простейший пример: пакет %name пишет %_logdir/%name.log и даже
еженедельно ротирует его через %_sysconfdir/logrotate.d/%name;
в результате этого появляются файлы %_logdir/%name.log.[1-3]

Теперь представь, что админ желает удалить пакет %name. Напрочь,
через rpm -e %name

В этом случае указание %ghost для всех этих логов позволяет их
вычистить вместе с пакетом, а не свинячить в системе.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rpm: symlink to dir

[Andrey Savchenko]

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

On Mon, 28 Dec 2020 23:10:15 +0300 Alexey V. Vissarionov wrote:
> On 2020-12-28 16:00:10 +0300, Andrey Savchenko wrote:
> 
>  > Если честно, я не совсем понимаю, зачем вообще нужен %gost.
> 
> %ghost
> 
>  > Я знаю, что он делает — позволяет закрепить несуществующий
>  > в пакете файл за пакетом — но мне представляется, что это
>  > ошибочная концепция и её использование говорит об ошибке в
>  > пакетировании пакета.
> 
> Простейший пример: пакет %name пишет %_logdir/%name.log и даже
> еженедельно ротирует его через %_sysconfdir/logrotate.d/%name;
> в результате этого появляются файлы %_logdir/%name.log.[1-3]
> 
> Теперь представь, что админ желает удалить пакет %name. Напрочь,
> через rpm -e %name
> 
> В этом случае указание %ghost для всех этих логов позволяет их
> вычистить вместе с пакетом, а не свинячить в системе.

За удаление логов вместе с пакетом нужно самое малое голову
отрывать.

Best regards,
Andrew Savchenko

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

Re: [devel] rpm: symlink to dir

[Alexey V. Vissarionov]

On 2020-12-28 23:16:31 +0300, Andrey Savchenko wrote:

 >>> Если честно, я не совсем понимаю, зачем вообще нужен %gost.
 >> %ghost
 >>> Я знаю, что он делает — позволяет закрепить несуществующий
 >>> в пакете файл за пакетом — но мне представляется, что это
 >>> ошибочная концепция и её использование говорит об ошибке в
 >>> пакетировании пакета.
 >> Простейший пример: пакет %name пишет %_logdir/%name.log и даже
 >> еженедельно ротирует его через %_sysconfdir/logrotate.d/%name;
 >> в результате этого появляются файлы %_logdir/%name.log.[1-3]
 >> Теперь представь, что админ желает удалить пакет %name. Напрочь,
 >> через rpm -e %name
 >> В этом случае указание %ghost для всех этих логов позволяет их
 >> вычистить вместе с пакетом, а не свинячить в системе.
 > За удаление логов вместе с пакетом нужно самое малое голову
 > отрывать.

С чего бы вдруг? Сам насвинячил, сам за собой убрал.
Кому нужны логи - `man cp` и `man rsync`.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] rpm: symlink to dir

[Andrey Savchenko]

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

On Mon, 28 Dec 2020 23:46:53 +0300 Alexey V. Vissarionov wrote:
> On 2020-12-28 23:16:31 +0300, Andrey Savchenko wrote:
> 
>  >>> Если честно, я не совсем понимаю, зачем вообще нужен %gost.
>  >> %ghost
>  >>> Я знаю, что он делает — позволяет закрепить несуществующий
>  >>> в пакете файл за пакетом — но мне представляется, что это
>  >>> ошибочная концепция и её использование говорит об ошибке в
>  >>> пакетировании пакета.
>  >> Простейший пример: пакет %name пишет %_logdir/%name.log и даже
>  >> еженедельно ротирует его через %_sysconfdir/logrotate.d/%name;
>  >> в результате этого появляются файлы %_logdir/%name.log.[1-3]
>  >> Теперь представь, что админ желает удалить пакет %name. Напрочь,
>  >> через rpm -e %name
>  >> В этом случае указание %ghost для всех этих логов позволяет их
>  >> вычистить вместе с пакетом, а не свинячить в системе.
>  > За удаление логов вместе с пакетом нужно самое малое голову
>  > отрывать.
> 
> С чего бы вдруг? Сам насвинячил, сам за собой убрал.

Это не мусор, это пользовательские данные. При удалении пакета не
должны удаляться результаты его работы. Ещё предложи грохать БД при
удалении mysql.

Впрочем, адепты DRM такой подход одобряют: они как раз мечтают
о самоуничтожении данных сразу после использования, но не ожидал,
что ты к ним относишься.

> Кому нужны логи - `man cp` и `man rsync`.

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

Best regards,
Andrew Savchenko

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

Re: [devel] rpm: symlink to dir

[Sergey V Turchin]

On Tuesday, 29 December 2020 09:31:27 MSK Andrey Savchenko wrote:

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

-- 
Regards, Sergey.

Re: [devel] rpm: symlink to dir

[Vladimir D. Seleznev]

On Tue, Dec 29, 2020 at 09:31:27AM +0300, Andrey Savchenko wrote:
> On Mon, 28 Dec 2020 23:46:53 +0300 Alexey V. Vissarionov wrote:
> > On 2020-12-28 23:16:31 +0300, Andrey Savchenko wrote:
> > 
> >  >>> Если честно, я не совсем понимаю, зачем вообще нужен %gost.
> >  >> %ghost
> >  >>> Я знаю, что он делает — позволяет закрепить несуществующий
> >  >>> в пакете файл за пакетом — но мне представляется, что это
> >  >>> ошибочная концепция и её использование говорит об ошибке в
> >  >>> пакетировании пакета.
> >  >> Простейший пример: пакет %name пишет %_logdir/%name.log и даже
> >  >> еженедельно ротирует его через %_sysconfdir/logrotate.d/%name;
> >  >> в результате этого появляются файлы %_logdir/%name.log.[1-3]
> >  >> Теперь представь, что админ желает удалить пакет %name. Напрочь,
> >  >> через rpm -e %name
> >  >> В этом случае указание %ghost для всех этих логов позволяет их
> >  >> вычистить вместе с пакетом, а не свинячить в системе.
> >  > За удаление логов вместе с пакетом нужно самое малое голову
> >  > отрывать.
> > 
> > С чего бы вдруг? Сам насвинячил, сам за собой убрал.
> 
> Это не мусор, это пользовательские данные. При удалении пакета не
> должны удаляться результаты его работы. Ещё предложи грохать БД при
> удалении mysql.

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

Кстати, файлы системного журнала _не_ помечены %ghost, что тоже логично.

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

> Впрочем, адепты DRM такой подход одобряют: они как раз мечтают
> о самоуничтожении данных сразу после использования, но не ожидал,
> что ты к ним относишься.
> 
> > Кому нужны логи - `man cp` и `man rsync`.
> 
> Не нужно за админов решать, что им нужно, а что грохнуть без спросу.
> Админы это не любят.

Ну, не совсем без спросу — админ же сам удалил пакет. Какие файлы
принадлежат пакету не является тайной. Не все файлы, принадлежащие
пакету, при этом, удаляются: например, могут остаться копии изменённых
конфигов с добавлением .rpmsave в имени файлов.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] rpm: symlink to dir

[Sergey V Turchin]

On Monday, 28 December 2020 16:00:10 MSK Andrey Savchenko wrote:

[...]
> Если честно, я не совсем понимаю, зачем вообще нужен %gost.
Пакет startup, файл /etc/firsttime.flag .

[...]

-- 
Regards, Sergey.

Re: [devel] rpm: symlink to dir

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 02:08:30AM +0300, Andrey Savchenko wrote:
[...]
> Проблема решается кардинально просто, но на уровне rpm: следует
> отказаться от концепции владельца директории и сохранять только
> владельцев файлов. Тогда что симлинк, что директория — разницы для
> PM никакой не будет. А удаляться они будут только если пустые. Ну
> если очень нужно пустую директорию установить, то можно в неё
> положить файлик '.keepdir'.

Некоторые каталоги имеют нетривиальные права доступа.


-- 
ldv

Re: [devel] rpm: symlink to dir

[Anton Farygin]

On 28.12.2020 02:21, Dmitry V. Levin wrote:
> On Mon, Dec 28, 2020 at 02:08:30AM +0300, Andrey Savchenko wrote:
> [...]
>> Проблема решается кардинально просто, но на уровне rpm: следует
>> отказаться от концепции владельца директории и сохранять только
>> владельцев файлов. Тогда что симлинк, что директория — разницы для
>> PM никакой не будет. А удаляться они будут только если пустые. Ну
>> если очень нужно пустую директорию установить, то можно в неё
>> положить файлик '.keepdir'.
> Некоторые каталоги имеют нетривиальные права доступа.
>
>
Я тоже не вижу других вариантов кроме %pretrans на lua.

А вообще планы перехода в обозримое время на новый rpm (не rpmbuild) у 
нас есть ?

Re: [devel] rpm: symlink to dir

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 09:11:19AM +0300, Anton Farygin wrote:
[...]
> Я тоже не вижу других вариантов кроме %pretrans на lua.

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

> А вообще планы перехода в обозримое время на новый rpm (не rpmbuild) у 
> нас есть ?

Вообще нас держит apt.  А что именно в новом rpm
(не rpmbuild) хотелось бы увидеть в первую очередь?


-- 
ldv

Re: [devel] rpm: symlink to dir

[Anton Farygin]

On 28.12.2020 12:04, Dmitry V. Levin wrote:
> On Mon, Dec 28, 2020 at 09:11:19AM +0300, Anton Farygin wrote:
> [...]
>> Я тоже не вижу других вариантов кроме %pretrans на lua.
> Самый логичный вариант - реализовать это в rpm.
> Но ради избавления от одного хака в год никому, видимо, это не интересно.
Я вообще слабо себе представляю человека, которому это было бы интересно 
и который готов был бы сделать эту работу именно по  такой причине.
>
>> А вообще планы перехода в обозримое время на новый rpm (не rpmbuild) у
>> нас есть ?
> Вообще нас держит apt.  А что именно в новом rpm
> (не rpmbuild) хотелось бы увидеть в первую очередь?
>
Поддержку %pretrans, я ведь правильно понимаю что нам нужно не сколько 
rpmbuild, сколько rpm ?

Re: [devel] rpm: symlink to dir

[Dmitry V. Levin]

On Mon, Dec 28, 2020 at 12:09:32PM +0300, Anton Farygin wrote:

> Поддержку %pretrans, я ведь правильно понимаю что нам нужно не сколько 
> rpmbuild, сколько rpm ?

Нет, в точности наоборот, в нынешнем rpm это давно есть.


-- 
ldv

Re: [devel] rpm: symlink to dir

[Andrey Savchenko]

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

On Mon, 28 Dec 2020 02:21:33 +0300 Dmitry V. Levin wrote:
> On Mon, Dec 28, 2020 at 02:08:30AM +0300, Andrey Savchenko wrote:
> [...]
> > Проблема решается кардинально просто, но на уровне rpm: следует
> > отказаться от концепции владельца директории и сохранять только
> > владельцев файлов. Тогда что симлинк, что директория — разницы для
> > PM никакой не будет. А удаляться они будут только если пустые. Ну
> > если очень нужно пустую директорию установить, то можно в неё
> > положить файлик '.keepdir'.
> 
> Некоторые каталоги имеют нетривиальные права доступа.

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

Best regards,
Andrew Savchenko

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

Re: [devel] rpm: symlink to dir

[Alexey V. Vissarionov]

On 2020-12-28 01:51:24 +0300, Leonid Krivoshein wrote:

 >>>> Есть ли текущая актуальная инструкция как при нашем новом
 >>>> rpm перейти в пакете с симлинка на директорию?
 >>> День добрый. Возник еще один пакет, где хотелось бы перейти с
 >>> симлинка на каталог на реальный каталог. Появилась инструкция
 >>> как это сделать?
 >> Насколько я понимаю, инструкции не было (я бы ее вряд ли
 >> пропустил). Безболезненный переход, по-моему, в принципе
 >> невозможен, а снизить ущерб мне удавалось только совсем
 >> очевидным (и столь же колхозным) способом с временным пакетом
 >> и переносом файлов в два этапа (у меня это были конфиги, так
 >> что размер не напрягал), но после этого в ОС оставался мусор
 >> в виде файлов, не охваченных пакетной системой.
 >> Использовать этот способ для дистрибутива, наверное, лучше
 >> не надо.
 > Предложил бы для всех подобных симлинков (каталогов):
 > - использовать специальный файл в корне со списком путей,
 > подлежащих замене типа (например, /.rpmlinks);

Какому пакету он будет принадлежать?

 > - замена должна производиться в initrd (stage1)

То есть, мимо пакетной системы? Отказать, отменить и запретить.

Не говоря уж о том, что система может загружаться и без initrd.

 > при первой же перезагрузке, пока никто там ничего не использует;
 > - от rpm требуется обработка такой ситуации и "понимание"
 > временно непригодного состояния (до перезагрузки).

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

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

 > Т.е., мне кажется, если реализовать поддержку одновременно
 > и в rpm, и в make-initrd, должно получиться относительно
 > безболезненно.

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net