* [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