* [devel] Bash completions packaging policy
@ 2019-09-30 20:08 Vladimir D. Seleznev
2019-10-01 3:59 ` Anton Farygin
0 siblings, 1 reply; 9+ messages in thread
From: Vladimir D. Seleznev @ 2019-09-30 20:08 UTC (permalink / raw)
To: devel
Hi!
Я обратил внимание, что в некоторых пакетах bash completions упаковываны
в /etc/bash_completion.d/, а в остальных — в
/usr/share/bash-completion/completions/.
Т.к. есть тенденция складывать настройки по-умолчанию в /usr/share/, а
локальные — в /etc/, то может быть нам упаковывать bash completions
только в /usr/share/bash-completion/completions/?
--
С уважением,
Владимир Селезнев
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] Bash completions packaging policy
2019-09-30 20:08 [devel] Bash completions packaging policy Vladimir D. Seleznev
@ 2019-10-01 3:59 ` Anton Farygin
2019-10-01 5:57 ` Alexey V. Vissarionov
0 siblings, 1 reply; 9+ messages in thread
From: Anton Farygin @ 2019-10-01 3:59 UTC (permalink / raw)
To: devel
On 30.09.2019 23:08, Vladimir D. Seleznev wrote:
> Hi!
>
> Я обратил внимание, что в некоторых пакетах bash completions упаковываны
> в /etc/bash_completion.d/, а в остальных — в
> /usr/share/bash-completion/completions/.
Точнее говоря - 98 пакетов держат bash-completion в /etc и 93 в /usr/share
>
> Т.к. есть тенденция складывать настройки по-умолчанию в /usr/share/, а
> локальные — в /etc/, то может быть нам упаковывать bash completions
> только в /usr/share/bash-completion/completions/?
Здесь также, как и в случае с именами пакетов python-module - лучше
подготовить policy.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] Bash completions packaging policy
2019-10-01 3:59 ` Anton Farygin
@ 2019-10-01 5:57 ` Alexey V. Vissarionov
2019-10-01 6:17 ` Anton Farygin
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Alexey V. Vissarionov @ 2019-10-01 5:57 UTC (permalink / raw)
To: ALT Linux Team development discussions
On 2019-10-01 06:59:06 +0300, Anton Farygin wrote:
>> Я обратил внимание, что в некоторых пакетах bash completions
>> упаковываны в /etc/bash_completion.d/, а в остальных — в
>> /usr/share/bash-completion/completions/.
> Точнее говоря - 98 пакетов держат bash-completion в /etc и
> 93 в /usr/share
>> Т.к. есть тенденция складывать настройки по-умолчанию в
>> /usr/share/, а локальные — в /etc/, то может быть нам
>> упаковывать bash completions только в
>> /usr/share/bash-completion/completions/?
> Здесь также, как и в случае с именами пакетов python-module - лучше
> подготовить policy.
И написать там про отдельные подпакеты для %name-bash-completion
--
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] Bash completions packaging policy
2019-10-01 5:57 ` Alexey V. Vissarionov
@ 2019-10-01 6:17 ` Anton Farygin
2019-10-01 6:41 ` Nikolai Kostrigin
2019-10-01 8:07 ` Andrey Savchenko
2 siblings, 0 replies; 9+ messages in thread
From: Anton Farygin @ 2019-10-01 6:17 UTC (permalink / raw)
To: devel
On 01.10.2019 8:57, Alexey V. Vissarionov wrote:
> On 2019-10-01 06:59:06 +0300, Anton Farygin wrote:
>
> >> Я обратил внимание, что в некоторых пакетах bash completions
> >> упаковываны в /etc/bash_completion.d/, а в остальных — в
> >> /usr/share/bash-completion/completions/.
> > Точнее говоря - 98 пакетов держат bash-completion в /etc и
> > 93 в /usr/share
> >> Т.к. есть тенденция складывать настройки по-умолчанию в
> >> /usr/share/, а локальные — в /etc/, то может быть нам
> >> упаковывать bash completions только в
> >> /usr/share/bash-completion/completions/?
> > Здесь также, как и в случае с именами пакетов python-module - лучше
> > подготовить policy.
>
> И написать там про отдельные подпакеты для %name-bash-completion
>
>
А вот этого делать не стоит, т.к. паразитные зависимости на bash не
появляются, а пара килобайт на диске никому не помешают.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] Bash completions packaging policy
2019-10-01 5:57 ` Alexey V. Vissarionov
2019-10-01 6:17 ` Anton Farygin
@ 2019-10-01 6:41 ` Nikolai Kostrigin
2019-10-01 8:07 ` Andrey Savchenko
2 siblings, 0 replies; 9+ messages in thread
From: Nikolai Kostrigin @ 2019-10-01 6:41 UTC (permalink / raw)
To: devel
01.10.2019 8:57, Alexey V. Vissarionov пишет:
>
> И написать там про отдельные подпакеты для %name-bash-completion
>
Для некоторых пакетов я считаю это сомнительным улучшением, т.к. рядовой
пользователь может не знать
о существовании полиси и будет лишен bash-completion по-умолчанию.
А в случае программ с развесистым и неочевидным списком аргументов будет
клясть мэнтэйнера на чем свет стоит.
--
Best regards,
Nikolai Kostrigin
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] Bash completions packaging policy
2019-10-01 5:57 ` Alexey V. Vissarionov
2019-10-01 6:17 ` Anton Farygin
2019-10-01 6:41 ` Nikolai Kostrigin
@ 2019-10-01 8:07 ` Andrey Savchenko
2019-10-01 9:23 ` Ivan A. Melnikov
2 siblings, 1 reply; 9+ messages in thread
From: Andrey Savchenko @ 2019-10-01 8:07 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]
On Tue, 1 Oct 2019 08:57:39 +0300 Alexey V. Vissarionov wrote:
> On 2019-10-01 06:59:06 +0300, Anton Farygin wrote:
>
> >> Я обратил внимание, что в некоторых пакетах bash completions
> >> упаковываны в /etc/bash_completion.d/, а в остальных — в
> >> /usr/share/bash-completion/completions/.
> > Точнее говоря - 98 пакетов держат bash-completion в /etc и
> > 93 в /usr/share
> >> Т.к. есть тенденция складывать настройки по-умолчанию в
> >> /usr/share/, а локальные — в /etc/, то может быть нам
> >> упаковывать bash completions только в
> >> /usr/share/bash-completion/completions/?
> > Здесь также, как и в случае с именами пакетов python-module - лучше
> > подготовить policy.
>
> И написать там про отдельные подпакеты для %name-bash-completion
Даже в Gentoo bash-completion *не* управляются отдельным
USE-флагом за исключением редких случаев, когда они тянут
дополнительные зависимости. Слишком мелкие файлы не влияющие на
работу самого приложения и овчинка выделки не стоит. Кому очень
нужно фильтровать, используют INSTALL_MASK на все пакеты. Думаю, при
создании образов для embedded ты можешь делать аналогичный фильтр.
Best regards,
Andrew Savchenko
[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] Bash completions packaging policy
2019-10-01 8:07 ` Andrey Savchenko
@ 2019-10-01 9:23 ` Ivan A. Melnikov
2019-10-01 12:08 ` [devel] Bash completions packaging policy (Q: упаковывать отдельно?) Vladimir D. Seleznev
0 siblings, 1 reply; 9+ messages in thread
From: Ivan A. Melnikov @ 2019-10-01 9:23 UTC (permalink / raw)
To: ALT Linux Team development discussions
On Tue, Oct 01, 2019 at 11:07:34AM +0300, Andrey Savchenko wrote:
> On Tue, 1 Oct 2019 08:57:39 +0300 Alexey V. Vissarionov wrote:
> > On 2019-10-01 06:59:06 +0300, Anton Farygin wrote:
> >
> > >> Я обратил внимание, что в некоторых пакетах bash completions
> > >> упаковываны в /etc/bash_completion.d/, а в остальных — в
> > >> /usr/share/bash-completion/completions/.
> > > Точнее говоря - 98 пакетов держат bash-completion в /etc и
> > > 93 в /usr/share
> > >> Т.к. есть тенденция складывать настройки по-умолчанию в
> > >> /usr/share/, а локальные — в /etc/, то может быть нам
> > >> упаковывать bash completions только в
> > >> /usr/share/bash-completion/completions/?
> > > Здесь также, как и в случае с именами пакетов python-module - лучше
> > > подготовить policy.
> >
> > И написать там про отдельные подпакеты для %name-bash-completion
>
> Даже в Gentoo bash-completion *не* управляются отдельным
> USE-флагом за исключением редких случаев, когда они тянут
> дополнительные зависимости. Слишком мелкие файлы не влияющие на
> работу самого приложения и овчинка выделки не стоит. Кому очень
> нужно фильтровать, используют INSTALL_MASK на все пакеты. Думаю, при
> создании образов для embedded ты можешь делать аналогичный фильтр.
Вот что-то такое и можно написать в policy про отдельные подпакеты
для %name-bash-completion ;)
--
wbr,
iv m.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] Bash completions packaging policy (Q: упаковывать отдельно?)
2019-10-01 9:23 ` Ivan A. Melnikov
@ 2019-10-01 12:08 ` Vladimir D. Seleznev
2019-10-01 12:14 ` Anton Farygin
0 siblings, 1 reply; 9+ messages in thread
From: Vladimir D. Seleznev @ 2019-10-01 12:08 UTC (permalink / raw)
To: ALT Linux Team development discussions
On Tue, Oct 01, 2019 at 01:23:44PM +0400, Ivan A. Melnikov wrote:
> On Tue, Oct 01, 2019 at 11:07:34AM +0300, Andrey Savchenko wrote:
> > On Tue, 1 Oct 2019 08:57:39 +0300 Alexey V. Vissarionov wrote:
> > > On 2019-10-01 06:59:06 +0300, Anton Farygin wrote:
> > >
> > > >> Я обратил внимание, что в некоторых пакетах bash completions
> > > >> упаковываны в /etc/bash_completion.d/, а в остальных — в
> > > >> /usr/share/bash-completion/completions/.
> > > > Точнее говоря - 98 пакетов держат bash-completion в /etc и
> > > > 93 в /usr/share
> > > >> Т.к. есть тенденция складывать настройки по-умолчанию в
> > > >> /usr/share/, а локальные — в /etc/, то может быть нам
> > > >> упаковывать bash completions только в
> > > >> /usr/share/bash-completion/completions/?
> > > > Здесь также, как и в случае с именами пакетов python-module - лучше
> > > > подготовить policy.
> > >
> > > И написать там про отдельные подпакеты для %name-bash-completion
> >
> > Даже в Gentoo bash-completion *не* управляются отдельным
> > USE-флагом за исключением редких случаев, когда они тянут
> > дополнительные зависимости. Слишком мелкие файлы не влияющие на
> > работу самого приложения и овчинка выделки не стоит. Кому очень
> > нужно фильтровать, используют INSTALL_MASK на все пакеты. Думаю, при
> > создании образов для embedded ты можешь делать аналогичный фильтр.
>
> Вот что-то такое и можно написать в policy про отдельные подпакеты
> для %name-bash-completion ;)
Только bash-completion-%name — в Альте префиксная традиция, а не
суффиксная :)
На самом деле хороший вопрос, стоит ли выделять bash completions в
отдельный подпакет. С одной стороны, мы хотели делать хорошо
гранулированную разбивку пакетов, хотя это не всегда и не всеми
мейнтейнерами поддерживается, и мне всегда было само собой разумеющимся,
что для completions надо поставить отдельный подпакет. С другой стороны,
есть два аргумента против:
1. Новым пользователям не очевидно, что completions упакованы отдельно.
На самом деле это слабый аргумент и больше относится к вопросу
документирования этой особенности альтосистем и изучения особенностей
новой системы пользователями.
Говорят, у нас с документированием плохо, и хотя возможно и не так, как
это кажется, какое-то количество тайных знаний у нас есть. Основные
особенности освещены тут [1], но тут только вскользь про саму разбивку
пакетов, а сама статья местами out of date: часть уже неактуально, много
чего можно дописать.
2. Практическая ценность.
Вот тут уже интереснее: я не смог обосновать для себя зачем нужно такое
разделение. Много места completions, как правило, не занимают, и обычно
не требуют дополнительных зависимостей. Более того, bash — default и
root shell, и при установке некого программного обеспечения довольно
естесственно хотеть функциональность completion'ов. В случае же
принципиального не использования completions пользователю необходимо и
достаточно отключить эту функциональность.
Возможно, стоит пересмотреть упаковку completions в отдельные
подпакеты. Например, упаковывать отдельно только при наличии
дополнительный тяжёлых зависимостей на них.
Ссылки:
[1] https://www.altlinux.org/Features
--
С уважением,
Владимир Селезнев
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [devel] Bash completions packaging policy (Q: упаковывать отдельно?)
2019-10-01 12:08 ` [devel] Bash completions packaging policy (Q: упаковывать отдельно?) Vladimir D. Seleznev
@ 2019-10-01 12:14 ` Anton Farygin
0 siblings, 0 replies; 9+ messages in thread
From: Anton Farygin @ 2019-10-01 12:14 UTC (permalink / raw)
To: devel
On 01.10.2019 15:08, Vladimir D. Seleznev wrote:
> 2. Практическая ценность.
>
> Вот тут уже интереснее: я не смог обосновать для себя зачем нужно такое
> разделение. Много места completions, как правило, не занимают, и обычно
> не требуют дополнительных зависимостей. Более того, bash — default и
> root shell, и при установке некого программного обеспечения довольно
> естесственно хотеть функциональность completion'ов. В случае же
> принципиального не использования completions пользователю необходимо и
> достаточно отключить эту функциональность.
Кстати да, по поводу практической ценности - с ростом количества пакетов
растёт нагрузка и на apt, включая инфраструктуру.
И, соответственно, практическая ценность для такого дробления заметно
падает.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-10-01 12:14 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-30 20:08 [devel] Bash completions packaging policy Vladimir D. Seleznev
2019-10-01 3:59 ` Anton Farygin
2019-10-01 5:57 ` Alexey V. Vissarionov
2019-10-01 6:17 ` Anton Farygin
2019-10-01 6:41 ` Nikolai Kostrigin
2019-10-01 8:07 ` Andrey Savchenko
2019-10-01 9:23 ` Ivan A. Melnikov
2019-10-01 12:08 ` [devel] Bash completions packaging policy (Q: упаковывать отдельно?) Vladimir D. Seleznev
2019-10-01 12:14 ` Anton Farygin
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git