А вот и не сделают! Для 1.2 есть потому что LSB, а для 1.4 слота нет.

ну значит в пакет 1.6 будет помечен как тестируемый на долгое время

а потом всё наебнётся после долгого времени. В генте с png такое происходит регулярно

> В генте с png такое происходит регулярно

вы хотите сказать - у вас в генте такое происходит регулярно?
ну так пересядьте на другой дистр, коль для вас гента слишком сложна.

или вам хочется и морковку съесть, и на ^W^W^W^W считать себя круче других(я gentoo 0дминю \m/.. у себя дома), и не читать хаутушки по обновлению мира (мануалы для ламеров \m/)?

> Меня всегда удивляло, как в библиотеке от которой требуется всего навсего сжимать/разжимать поток данных

Ты путаешь libpng с zlib. libpng приходится делать хренову тонну вещей, посмотри хедер хотя бы если настолько в танке.

> можно ломать api чуть ли не с каждым выходом 1.x.0, да еще иногда, так что поправить с ходу это было нелегко

Чтобы поправить сходу было нелегко - такого не было. А стабильность API - это величайшее зло. Кривоваты ручки обновляться - не обновляйтесь, никто не заставляет.

>А стабильность API - это величайшее зло. Кривоваты ручки обновляться - не обновляйтесь, никто не заставляет.

Не люблю крайностей. Должна быть золотая середина и разумный баланс. Крайность суждений свидетельствует о незрелости.

Похерил API - меняй soname, блеать!!

> Должна быть золотая середина и разумный баланс.

Оно и есть. soname меняется, срок на deprecated даётся более чем достаточный. Но всё равно найдутся нытики-лентяи.

> Ты путаешь libpng с zlib. libpng приходится делать хренову тонну вещей, посмотри хедер хотя бы если настолько в танке.

Я в своей программе использую:
extern (C) png_struct* png_create_write_struct(immutable(char)*, void*, void*, void*);
extern (C) png_info_struct* png_create_info_struct(png_struct*);
extern (C) void png_init_io(png_struct*, FILE*);
extern (C) void png_set_IHDR(png_struct*, png_info_struct*, uint, uint, int, int color_type, int interlace_method, int compression_method, int filter_method);
extern (C) void png_set_pHYs(png_struct*, png_info_struct*, uint res_x, uint res_y, int unit_type);
extern (C) void png_write_info(png_struct*, png_info_struct*);
extern (C) void png_write_image(png_struct*, ubyte**);
extern (C) void png_write_end(png_struct*, png_info_struct*);

только для того чтобы просто сохранить изображение из памяти (raw rgba) в png. Это нормальный API? Такая простая операция должна выполнятся одной функцией, максимум двумя. Многие приложения вообще не работают с libpng напрямую, а используют прослойки типа freeimage. Похоже и до авторов библиотеки дошло - что навороты хорошо, но нужны они очень редко.

> Это нормальный API?

Для таких как вы, видимо, и сделали упрощённый API. И да, это нормалньый API, потому что просто сохранить rgba в png - это хорошо, но нужно это очень редко, и обычно нужна гораздо более широкая функциональность.

Приведите обычный пример, который применяется чаще (хотя бы не реже), чем просто сжать/распаковать в память/файл,  где нужна большая функциональность, а то сразу что-то даже ничего в голову не приходит.

Разве вы не написали уже свою функцию my_write_png_file() ?

> Чтобы поправить сходу было нелегко - такого не было.

Посмотри как gimp-2.7 переходил на новую версию. Я после обновления libpng сам хотел поправить, так как с другими библиотеками никогда проблем не было: максимум что-то переименовать или добавить параметр, а тут ... Хорошо нашел патч от другой версии гимпа и по аналогии поправил да и то кривовато, ибо по хорошему нужно было вникать гораздо глубже.

Каждый раз при выходе новой версии libpng 1.x нужно пересобирать всё ПО, от неё зависящее — факт.

У этой библиотеки принципы модульности и обратной совместимости не в моде.

> Каждый раз при выходе новой версии libpng 1.x нужно пересобирать всё ПО,
> от неё зависящее — факт.
> У этой библиотеки принципы модульности и обратной совместимости не в моде.

Недавно вышла 1.5.14 скоро выйдет 1.5.15, вовсе необязательно перепрыгивать на ветку 1.6.x прямо сейчас, да и вообще в ближайшее время.

> Недавно вышла 1.5.14 скоро выйдет 1.5.15, вовсе необязательно перепрыгивать на ветку 1.6.x прямо сейчас, да и вообще в ближайшее время.

Когда перепрыгивать, решают мантейнеры портов.

> Каждый раз при выходе новой версии libpng 1.x нужно пересобирать всё ПО,
> от неё зависящее — факт.

Нет. У вас же есть portupgrade/portmaster которые сохраняют старые версии библиотек, и такой хренью как в gentoo можно не страдать пока сильно не захочется.

Совет использовать "pormaster -w" в /usr/ports/UPDATING  для libpng (пакет png) что-то не припомню. http://www.freshports.org/graphics/png/ — каждый раз: "portmaster -r png-" или "portupgrade -fr graphics/png".

> Совет использовать "pormaster -w" в /usr/ports/UPDATING  для libpng (пакет png) что-то
> не припомню. http://www.freshports.org/graphics/png/ — каждый раз: "portmaster
> -r png-" или "portupgrade -fr graphics/png".

А тебе что, для каждого апдейта библиотеки должны в UPDATING писать? Не делаешь -w - сам дебил. portupgrade так по умолчанию сошки сохраняет.

зачем, когда есть фотошоп?

>  зачем, когда есть фотошоп?

и не поспориш xD

настолько неожиданно, что даже не толсто

Фотошоп тоже на новую 1.6 обновится, не переживайте. Только узнаем мы об этом через 100 лет из музея компьютерной техники.

Ну вот, опять обновлять всю систему. К libpng призывается всё: Qt, gtk, cairo, pango, fontconfig, freetype - сотни системных компонентов! И все пересобирать. Когда я обновлял систему с libpng 1.4 до 1.5 у Cairo возникла цикличная зависимость. Он не собирался, так как librsvg собран с libpng14, а librsvg не собирался потому что Cairo собран с libpng14. Решил проблему удалением librsvg и сборкой Cairo без него (причём скомпилировалось с поддержкой svg, что удивительно), а затем установкой этой библиотеки заново. В общем, еле обновил, а теперь, видимо, снова придётся сделать это.

> Ну вот, опять обновлять всю систему. К libpng призывается всё: Qt, gtk,
> cairo, pango, fontconfig, freetype - сотни системных компонентов! И все пересобирать.
> Когда я обновлял систему с libpng 1.4 до 1.5 у Cairo
> возникла цикличная зависимость. Он не собирался, так как librsvg собран с
> libpng14, а librsvg не собирался потому что Cairo собран с libpng14.
> Решил проблему удалением librsvg и сборкой Cairo без него (причём скомпилировалось
> с поддержкой svg, что удивительно), а затем установкой этой библиотеки заново.
> В общем, еле обновил, а теперь, видимо, снова придётся сделать это.

А что у вас за недосистема что она не умеет сохранять старые версии библиотек, чтобы и без пересборки всего это всё работало?

> А что у вас за недосистема что она не умеет сохранять старые
> версии библиотек, чтобы и без пересборки всего это всё работало?

Может у него LFS ;-) Или FreeBSD, или Arch.

Фря умеет сохранять старые либы.

Нет, фряшные порты не умеют.

Порты и не должны этого уметь.
potrmaster -w

Как там ваш дядька в Киеве?

А просто не обновлять libpng что, религия не позволяет? package.mask там или portmaster -x...
И вообще, есть хороший принцип "работает -- не трогай". Одно дело -- разрабы дистров, а другое -- сборище маньяков, обновляющих ради процесса.

> А просто не обновлять libpng что, религия не позволяет? package.mask там или
> portmaster -x...
> И вообще, есть хороший принцип "работает -- не трогай". Одно дело --
> разрабы дистров, а другое -- сборище маньяков, обновляющих ради процесса.

А переписывать программы при каждой смене libpng разработчикам/мэинтейнерам это значит нормально? А потом в программе приходится липить кучу #ifdef на каждую версию библиотеки ибо не угадаешь, что будет у пользователя.

> А переписывать программы при каждой смене libpng разработчикам/мэинтейнерам это значит
> нормально?

Абсолютно. Ленивому ламерью западло, но оно может забандлить libpng любой протухшей версии. Иначе либо библиотека ничего бы не умела либо была бы набором костылей для сохранения совместимости ради, опять же, ламерья.

>> А переписывать программы при каждой смене libpng разработчикам/мэинтейнерам это значит
>> нормально?
> Абсолютно. Ленивому ламерью западло, но оно может забандлить libpng любой протухшей версии.
> Иначе либо библиотека ничего бы не умела либо была бы набором
> костылей для сохранения совместимости ради, опять же, ламерья.

Правильно, зачем хранить собственные костыли в одном месте? Пусть лучше каждый разработчик использующий libpng самостоятельно напишет их в своей программе.

>>> А переписывать программы при каждой смене libpng разработчикам/мэинтейнерам это значит
>>> нормально?
>> Абсолютно. Ленивому ламерью западло, но оно может забандлить libpng любой протухшей версии.
>> Иначе либо библиотека ничего бы не умела либо была бы набором
>> костылей для сохранения совместимости ради, опять же, ламерья.
> Правильно, зачем хранить собственные костыли в одном месте? Пусть лучше каждый разработчик
> использующий libpng самостоятельно напишет их в своей программе.

зато как значимость библиотеки возрастает...

> Правильно, зачем хранить собственные костыли в одном месте? Пусть лучше каждый разработчик
> использующий libpng самостоятельно напишет их в своей программе.

Нет, костылей в коде быть вообще не должно. Крайнее им место - в портах/пакетах.

лох дело говорит

apng?

...добавляется отдельным патчем.

pngOS

А какой глобальный смысл в удалении устаревшего кода? Ну сохранили бы со статусом "obsolete" - и фиг с ним. Зачем создавать проблемы тем, чьи проблемы ты должен решать?

> сохранили бы со статусом "obsolete" - и фиг с ним.
> фиг с ним

Windows way?

> А какой глобальный смысл в удалении устаревшего кода? Ну сохранили бы со
> статусом "obsolete" - и фиг с ним. Зачем создавать проблемы тем,
> чьи проблемы ты должен решать?

Чистить код нужно постоянно - чем меньше кода, тем выше его читаемость, меньше ошибок, легче портировать.

Чистить API тоже нужно, но сперва пометить как deprecated и лишь через пол года - год удалять. Да и как правило библиотеки с хорошим дизайном редко сильно меняют API, в основном просто расширяют, соответственно обратная совместимость не ломается.

> Чистить API тоже нужно, но сперва пометить как deprecated и лишь через пол года - год удалять.

Сами это написали, а выше ныли как страшно переписывать под новые версии. libpng так и делают, только времени доют ещё больше.

>> Чистить API тоже нужно, но сперва пометить как deprecated и лишь через пол года - год удалять.
> Сами это написали, а выше ныли как страшно переписывать под новые версии.
> libpng так и делают, только времени доют ещё больше.

Как раз с libpng и возникают проблемы, ибо программа собраная с ее поддержкой жестко привязывается к конкретной версии. Примеры уже здесь приводили. Ни с одной другой библиотекой такого не наблюдается. Даже glibc проще обновить.

Где это они времени больше дают? Что-то не припомню при компиляции "Warning: xxxx this function depricated", за то вот error'ы как грибы после дождя, если версия не совпала.

> Где это они времени больше дают?

Ну вот к примеру что можно найти в libpng-manual.txt в разделе где перечисляются изменения между 1.2.x и 1.4.x:

The functions png_read_init(info_ptr), png_write_init(info_ptr),
png_info_init(info_ptr), png_read_destroy(), and png_write_destroy()
have been removed.  They have been deprecated since libpng-0.95.

The png_permit_empty_plte() was removed. It has been deprecated
since libpng-1.0.9.  Use png_permit_mng_features() instead.

Вот только на практике при попытке собрать приложение написанное под API 1.2.x с новой 1.4.x заканчивается кучей ошибок, а не warning'ов.

Я использую D как основной язык, так там API основной библиотеки долгое время был крайне нестабилен - ибо язык очень быстро развивался, но при этом я не ощущал от этого большого дискомфорта, так как реально старый API переставал работать только через продолжительный срок и при каждой компиляции я видел, что функция deprecated и дату/версию в которой ее удалят.

> Вот только на практике при попытке собрать приложение написанное под API 1.2.x
> с новой 1.4.x заканчивается кучей ошибок, а не warning'ов.

В ветке 1.2.x ширину изображения можно было получить двумя способами:
info_ptr->width
png_get_image_width()

В ветке 1.4.x прямой доступ убрали как небезопасный и оставили только
png_get_image_width()

Именно это изменение вызвало наибольший дискомфорт: во многих старых приложениях был прямой доступ и видимо разработчики libpng не смогли придумать, как сделать чтобы чтение info_ptr->width некоторое время работало, но предупреждало, что этот подход deprecated...

По сравнению с этим, переход от 1.4.x к 1.5.x был относительно безболезненным, думаю 1.6.x тоже пройдет без особых проблем.

> Как раз с libpng и возникают проблемы, ибо программа собраная с ее
> поддержкой жестко привязывается к конкретной версии. Примеры уже здесь приводили. Ни
> с одной другой библиотекой такого не наблюдается. Даже glibc проще обновить.

И в glibc есть deprecated, и вообще вы сколько бибилотек пользуете? Я постоянно вижу развивающиеся (причём не ценой сотен костылей, а через устаревание старых интерфейсов) API, и это правильно. "Приводите" вы здесь один страдалец, и всё, что характерно, мимо.

Прошлое многочасовое обновление с libpng 1.2 до 1.5 было со слезами на глазах и почти истерикой.