[devel] ALT_2.24 (was: [#175881] p8 FAILED copy=SDL)

[Alexey Tourbin <alexey.tourbin@gmail.com>]

On Sat, Jan 7, 2017 at 10:22 PM, Girar Builder awaiter robot
<girar-builder@altlinux.org> wrote:
> http://git.altlinux.org/tasks/175881/logs/events.1.1.log
>
> 2017-Jan-07 19:20:28 :: test-only task #175881 for p8 started by mike:
> #100 copy SDL from sisyphus
> 2017-Jan-07 19:20:30 :: copy from `sisyphus': SDL-1.2.14-alt7.src.rpm
> 2017-Jan-07 19:20:36 :: build check OK
> 2017-Jan-07 19:20:36 :: noarch check OK
> 2017-Jan-07 19:20:38 :: plan: src +1 -1 =17510, i586 +3 -3 =33884, x86_64 +3 -3 =33833
> 2017-Jan-07 19:20:38 :: version check OK
> 2017-Jan-07 19:21:54 :: generated apt indices
> 2017-Jan-07 19:21:54 :: created next repo
>         i586: NEW unmet dependencies detected:
> libSDL#1.2.14-alt7              libc.so.6(ALT_2.24)
>         x86_64: NEW unmet dependencies detected:
> libSDL#1.2.14-alt7              libc.so.6(ALT_2.24)(64bit)

Мужчины, это всё не очень хорошо. Своего интерфейса ALT_2.24 быть не должно.

В свое время генеральный конструктор озвучивал тезис: нас интересует
только запускаются ли программы из других дистрибутивов у нас;
запускаются ли наши программы в чужих дистрибутивах, нас не
интересует. Ну слушайте, эта асимметрия абсурдна по крайней мере в
этической плоскости. Это примерно как сказать, что если сдохла корова
у нас - то это нас интересует; а если у американцев - то слава богу,
не интересует!

$ readelf --wide --dyn-sym /lib64/libc.so.6 |grep ALT
   155: 00000000000f64e0    25 FUNC    GLOBAL DEFAULT   13
__strlcpy_chk@@ALT_2.24
   352: 00000000000f6500    25 FUNC    GLOBAL DEFAULT   13
__strlcat_chk@@ALT_2.24
  1671: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS ALT_2.24

С другой стороны, когда это всё висело на GLIBC_2.2, то это тоже было
не очень хорошо. Потому что это было обман.

У вас зависимость на интерфейс ALT_2.24 получат не отдельные редкие
пакеты, а массово все X-овые пакеты, потому что они кагбе BSD-шные и
там этот strlcpy везде пустил метастазы.

Когда я обдумывал эту тему где-то в 2011 году, я пришел к выводу, что
наименьшим из зол будет подключение strlcpy по линии -lc со стороны
статической библиотеки, кажется она называлась libc_nonshared.a.
По-моему, именно так тогда было сделано в дистрибутиве Owl. Возможен
также более или мене полный или частичный отказ от strlcpy в glibc
(можно, например, попытаться сделать символы недефолтными, чтобы они
все еще предоставлялись, но чтобы с ними уже нельзя было
слинковаться).