ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: "Vladimir D. Seleznev" <vseleznv@altlinux.org>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] Bash completions packaging policy (Q: упаковывать отдельно?)
Date: Tue, 1 Oct 2019 15:08:17 +0300
Message-ID: <20191001120817.GA3910679@portlab> (raw)
In-Reply-To: <20191001092344.4zzhdvdehbciosar@titan.localdomain>

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

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


  reply	other threads:[~2019-10-01 12:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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         ` Vladimir D. Seleznev [this message]
2019-10-01 12:14           ` [devel] Bash completions packaging policy (Q: упаковывать отдельно?) Anton Farygin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191001120817.GA3910679@portlab \
    --to=vseleznv@altlinux.org \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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