From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 7 Sep 2020 18:10:43 +0300 From: Michael Shigorin To: devel-distro@lists.altlinux.org Message-ID: <20200907151043.GH5319@imap.altlinux.org> References: <1cd8e7f9-4dc3-1eeb-268f-84c0d36a3204@ya.ru> <2720537.NgBsaNRSFp@zerg.malta.altlinux.ru> <20200907135600.GB5319@imap.altlinux.org> <5333050.LvFx2qVVIh@zerg.malta.altlinux.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5333050.LvFx2qVVIh@zerg.malta.altlinux.ru> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [devel-distro] =?koi8-r?b?0MXSxdfPxNksINPQydPLySwgxs/Sy8kgKHdh?= =?koi8-r?b?czogy8/NzcnU2SDEzNEga3dvcmtzdGF0aW9uKQ==?= X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2020 15:10:44 -0000 Archived-At: List-Archive: On Mon, Sep 07, 2020 at 05:36:43PM +0300, Sergey V Turchin wrote: > > > > или -- как в данном разе -- подключать переводчиков и > > > > обеспечивать переводы вместо потери важной _целевой_ > > > > функциональности. > > > Ты в курсе прогресса работ в этом направлении. > > Потому вдвойне и удивился. :-) Хорошо же делают. > Делают, но не сделали. А коммит был, когда перевода не было вообще. Ты бы посмотрел, когда там "не было вообще". В альт я собирал, помнится, уже переведя. > > > > 2 zerg: в таких случаях в m-p по задумке принято не калечить > > > > списки общего пользования, > > > У меня другое мнение: я их исправил. > > Обоснуй. Это я в т.ч. как майнтейнер и многолетний активный > > пользователь recoll спрашиваю. > Пользуйся на здоровье, но не путай, пожалуйста, себя > и пользователя дистрибутива. И что, пара непереведённых строк в конфигурации индексирования новой версии прям-таки сломает ему жизнь и выпьет кофе? Ты забыл обосновать своё мнение. Если оно чисто субъективное -- тогда этот коммит стоит откатить, если взяли, потому что моё чисто субъективное мнение указано выше: это регрессия для m-p, а в kworkstation с особыми требованиями к переводам следует использовать какие-то отдельные списки (и, возможно, автотест для определения стопроцентности перевода и блокирования сборки в случае нарушения этого критерия -- см. в качестве примера features.in/rescue/rescue/image-scripts.d/00-test-rescue). > > > > а или выделять нужную часть, > > > Мне неудобно городить своё отдельное дерево и отслеживать > > > изменения в тех местах, которые я копирую. > > Тогда учись договариваться, > Так я сразу же предлагал договариваться. ;-) Уже хорошо :-) > > а не как с branding-xalt-kworkstation, который теперь в > > версиях системных компонент вроде xorg-server "красуется": > > "мне так удобно, а до вас всех мне дела нет" :-/ > А кому конкретно должно быть удобно или не удобно в этом случае? Более правильное решение тогда реализовал manowar@, загляни в фичу pkgpriorities или просто git grep PINNED_PACKAGES. > > На сейчас предусмотрены варианты: > > 1) общих списков/фич, которые должны устраивать _всех_ > > пользователей данной ветки (и исправляться/улучшаться > > коллегиально); > Будем коллегиально выбирать между черным и белым, при этом > половине нужно одно, а второй другое? ;-) Такие случаи тоже, разумеется, бывают -- для этого и сделана возможность предложить и применять свои списки (так сказать, создать свой монастырь со своим уставом). Если приходится двигать фундамент -- это, конечно, сложнее, но порой тоже бывает осмысленным (если бы была возможность последние пять лет хоть иногда добираться до выпуска livecd с игрушками -- возможно, у тебя не возникла бы такая нужда уже для kworkstation; но уж как есть). > > И выделить rescue+x11+extra, а "себе" забирать булевым выражением > > $(call tags,rescue && x11 && !extra) > > вместо > > $(call tags,rescue x11) > > -- по-моему, не так уж и сложно, было бы желание. > Ок, возмьму на вооружение. > Осталось для целей в make-файлах что-то придумать. С целями труднее всего, угу. Но порой можно выкрутиться как-то вроде $(ISOHYBRID:%=use/isohybrid) в фиче syslinux или $(UBOOT_TTY) в uboot. Здесь сходу не вижу варианта. В любом случае, напоровшись на проблему -- постарайся черкнуть хоть полстроки сюда или набросок патча, пока с ним собирается. Вдруг "о, а похожее уже решали" у кого возникнет. > > > Вся суть m-p и состоит в разобщении списков. [...] > > > Это его главный недостаток, который следует исправить. > > Поясни, пожалуйста. > Свои списки у каждого дистрибутива. Оно-то да, но тут тоже есть что аккуратно обобщать. Например, у меня тут лежат коммиты для фичи office, которые после выпуска стартеркитов будем смотреть и, надеюсь, мержить вместо того, чтоб по спискам пакетов таскать хитрые исключения для конкретных архитектур: http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles.git;a=shortlog;h=refs/heads/next (2 antohami: пока не торопись, там были правки regular.mk и между бетой и выпуском я бы их не стал предлагать) > Выше указал на частичное решение, спасибо! Ура :-) > > PS: смотрел выхлоп REPORT=1 при установленном graphviz? > Нет. Появился повод выбросить мусор и свой и чужой. Чтоб выбрасывать чужой мусор, надо очень хорошо понимать в нём -- ответственность куда больше, чем со своим... --  ---- WBR, Michael Shigorin / http://altlinux.org   ------ http://opennet.ru / http://anna-news.info