From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 27 Apr 2020 11:56:10 +0300 From: Michael Shigorin To: devel@lists.altlinux.org Message-ID: <20200427085610.GF7900@imap.altlinux.org> References: <20200417235446.GB31146@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [devel] =?koi8-r?b?X19saWJjX2VuYWJsZV9zZWN1cmUg1yBvcGVuc3NsICBs?= =?koi8-r?b?aWJjcnlwdG8=?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 08:56:10 -0000 Archived-At: List-Archive: List-Post: On Mon, Apr 27, 2020 at 11:30:47AM +0300, Mikhail Novosyolov wrote: > Единственным выходом из ситуации я вижу попытки рекомендовать > разработчикам собирать универсальные исполняемые файлы или > пакеты с грамотно сбандленными библиотеками и грамотно > прописанные зависимости в RPM, например, не libgnomekeyring, > a libgnome-keyring.so.0()(64bit). Тянет на небольшой образовательный центр, как мне кажется. Хотя ИСП РАН может оказаться при делах, глядишь, сделают "русский LSB" ;-) > Была мысль, что многим будет гораздо проще не изобретать > сложную систему сборки с частичной статической линковкой, > а собирать с системными библиотеками в какой-нибудь ОС, > а затем упаковывать AppImage, это очень просто. Чревато невоспроизводимостью, поскольку будет искушать что-нить напихать/допилить вручную (особенно в аврал). > AppImage-подобную структуру можно положить в RPM-пакет, > зная про AutoReq, AutoProv и др. И вот здесь встает вопрос, > насколько помешают такие фокусы. Соберут в Альте - не > заработает в других дистрибутивах. Тот же openssl настолько > часто используется и однозначно будет сбандливаться, что Альт > можно сразу не рекомендовать для сборки AppImage-подобных > пакетов. А вот если собрать ПО на другом дистрибутиве, то есть > небольшая вероятность возникновения проблем в Альте. Думаю так: - если тяп-ляп, то собирать надёжней всего на чём-то вроде centos6 -- оно достаточно дубовое и консервативное по части ABI, чтобы на обратной совместимости работало более-менее везде (варианты сборки под более развесистые/заточенные наборы интерфейсов мне кажутся прогрессирующей рулеткой); - если учиться делать по уму, то учиться собирать "нативно" (в плане ABI) на альте весьма полезно для получения заодно и покрытия автоматическим контролем качества упаковки от нашего инструментария -- что может быть полезно на любом другом как минимум линуксе. Кстати, Вы слышали про http://wiki.etersoft.ru/korinf? > Думаю, что нужно сильно постараться, чтобы их поймать, т.к. > внутренний API __libc_enable_secure заведомо не стоит > использовать, но, может быть, есть другие подобные нюансы. Ещё у нас ncurses была на что-то из glibc завязана, помнится. --  ---- WBR, Michael Shigorin / http://altlinux.org   ------ http://opennet.ru / http://anna-news.info