LINUX.ORG.RU

Планы по кросс-форматному пакетному API в LSB


0

0

Одна из главных проблем в поддержке GNU/Linux - огромное количество пакетных менеджеров и их несовместимость. Однако, следующая версия Linux standart base (LSB) может помочь решить эту проблему предоставляя программный интерфейс (API), который выполнит функции связующего звена между основными пакетами программного обеспечения, системами и установщиками. Ян Мердок, директор Free Standards Group утверждает, что эти решения могут быть включены в наиболее распространённые дистрибутивы уже в начале 2008 года. Он отмечает, что установка ПО для конечного пользователя значительно упростилась в последние годы, dpkg и yum стали нормой. Мердока поддержали представители Novell и Red Hat. Руководитель проекта Fedora Макс Спевак: "Похоже, хороший способ выйти из тупика -- API, который может работать поверх существующих систем установки, представляется более вероятным, чем пытаться создавать новую систему с нуля". Мердок надеется, что такое API станет частью LSB версии 4.0, и что следующие версии Red Hat Enterprise Linux, SUSE, Debian и дистрибутивы основанные на них переработают свои пакетные менеджеры с поддержкой этого стандарта.

>>> Подробности

★★

Проверено: Shaman007 ()

Re: Планы по кросс-форматному пакетному API в LSB

>>Фактически, нужно поддерживать некоторое количество PM'ов, кое невелико, и LSB.

>Это все равно дорого.

Фактически нужно поддерживать только LSB (== RPM). И если им это дорого, то... почему проблемы белых шерифов должны решать индейцы?

tailgunner ★★★★★ ()

Re: Планы по кросс-форматному пакетному API в LSB

>А как её использовать-то?

man почитай.

В своё время Loki обновления для игрушек в таком виде выпускала "чиста-канкретный" бинарный diff в чистом виде.

sS ★★★★★ ()

Re: Планы по кросс-форматному пакетному API в LSB

>В своё время Loki обновления для игрушек в таком виде выпускала "чиста-канкретный" бинарный diff в чистом виде.

Новелл так апдейты дистров - xdelta на iso образы.

r ★★★★★ ()

Re: Планы по кросс-форматному пакетному API в LSB

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

Это целый новый класс проблем со сборкой и проблем возникающих конкретно с твоими CFLAGS и USE-флагами.

Ну например спонтанные вот такие проблемы решающиеся пересборкой:

../include/link.h:90: error: expected specifier-qualifier-list before 'ElfW'
../include/link.h:290:3: error: #error "__ELF_NATIVE_CLASS must be defined"
../include/link.h:294: warning: 'struct dl_phdr_info' declared inside parameter list
../include/link.h:294: warning: its scope is only this definition or declaration, which is probably not what you want
make[2]: *** [/var/tmp/portage/glibc-2.4-r4/work/build-default-i686-pc-linux-gnu-nptl/iconvda ta/cp1257.os] Error 1
make[2]: Leaving directory `/var/tmp/portage/glibc-2.4-r4/work/glibc-2.4/iconvdata'
make[1]: *** [iconvdata/others] Error 2
make[1]: Leaving directory `/var/tmp/portage/glibc-2.4-r4/work/glibc-2.4'
make: *** [all] Error 2

!!! ERROR: sys-libs/glibc-2.4-r4 failed.

Или вот такие:

anonymous@somebox ~/test/profiler $ gcc example2.c -ggdb3 -pg -o example2 -O2 -lc_p
example2.c: In function 'main':
example2.c:19: warning: incompatible implicit declaration of built-in function 'exit'
anonymous@somebox ~/test/profiler $ ./example2
Floating point exception
anonymous@somebox ~/test/profiler $ gdb ./example2
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

gdb> r

Program received signal SIGFPE, Arithmetic exception.
Error while running hook_stop:
Invalid type combination in ordering comparison.
0x08053c35 in profil ()

Да, это все, кстати, ветка STABLE.

anonymous ()
Ответ на: Re: Планы по кросс-форматному пакетному API в LSB от watashiwa_daredeska

Re: Планы по кросс-форматному пакетному API в LSB

> Замечательно! Если сейчас всякое левое барахло с собственными инсталляторами отправляется в /usr/local, то по этому стандарту, оно спросит у менеджера пакетов пути и засрёт /usr. Винда forever!

Вызывающе неверная информация. Там еще и теневые каталоги будут.

Aceler ★★★★★ ()

Re: Планы по кросс-форматному пакетному API в LSB

> Только это и есть true. Система управления пакетами в слакваре самая лучшая, удобная и понятная. Но если думать непривычно, то, конечно, да, юзайте rpm.

Конфликты с разделяемыми библиотеками самостоятельно разбирать?

Aceler ★★★★★ ()

Re: Планы по кросс-форматному пакетному API в LSB

> Зачем для них изобретать ещё один велосипед?

В первую очередь из-за разделяемых библиотек. Если программа тащит их с собой, то есть риск нарваться на конфликт файлов. Если не тащит - на риск, что библиотеки не будет. Не пользоваться разделяемыми библиотеками?

Aceler ★★★★★ ()
Ответ на: Re: Планы по кросс-форматному пакетному API в LSB от watashiwa_daredeska

Re: Планы по кросс-форматному пакетному API в LSB

> Речь о том, что не будет RPM'ов, вместо RPM'а --- инсталлер (как привыкли в Винде) и API (как в Винде --- можно спросить где Program Files, куда ярлыки для десктопа сваливать).

Вот это уже совсем неверная информация, если бы было так, мы бы уже переехали на это API. Идея как раз в том, чтобы сделать метапакетный менеджер, в который можно будет добавлять пакеты из любого пакетного менеджера или инсталлятора.

Aceler ★★★★★ ()

Re: Планы по кросс-форматному пакетному API в LSB

> вот бы кстати еще p7zip вместо gzip использовали, размеры пакетов уменьшились бы очень существенно, огромная экономия трафика, но, менять формат, опять накладно, опять проблемы..

В принципе, для бинарных пакетов вообще без разницы чего юзать... BTW, в rpm не gzip, а cpio.

Aceler ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.