[devel] libexec and x86_64

[devel] libexec and x86_64

[@ 2005-10-27 9:38 UTC (permalink / raw)]

Re: [devel] libexec and x86_64

[@ 2005-10-27 12:42 UTC (permalink / raw)]

Re: [devel] libexec and x86_64

[@ 2005-10-27 18:56 UTC (permalink / raw)]

Re: [devel] libexec and x86_64

[@ 2005-10-27 19:49 UTC (permalink / raw)]

Re: [devel] libexec and x86_64

[@ 2005-10-27 19:50 UTC (permalink / raw)]

Re: [devel] libexec and x86_64

[@ 2005-10-27 20:11 UTC (permalink / raw)]

Re: [devel] libexec and x86_64

[@ 2005-10-27 21:51 UTC (permalink / raw)]

[devel] Re: libexec and x86_64

[@ 2005-10-28 7:59 UTC (permalink / raw)]

Re: [devel] Re: libexec and x86_64

[@ 2005-10-28 15:14 UTC (permalink / raw)]

Re: [devel] Re: libexec and x86_64

[@ 2005-10-29 14:48 UTC (permalink / raw)]

Re: [devel] Re: libexec and x86_64

[@ 2005-10-29 15:03 UTC (permalink / raw)]

Re: [devel] Re: libexec and x86_64

[@ 2005-10-30 19:51 UTC (permalink / raw)]

Re: [devel] Re: libexec and x86_64

[@ 2005-10-30 20:34 UTC (permalink / raw)]

Re: [devel] Re: libexec and x86_64

[@ 2005-10-30 20:39 UTC (permalink / raw)]

Re: [devel] Re: libexec and x86_64

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

On Sun, Oct 30, 2005 at 11:39:15PM +0300, Денис Смирнов wrote:
> On Sun, Oct 30, 2005 at 10:51:26PM +0300, Dmitry V. Levin wrote:
> 
> >> У меня asterisk такой -- в зависимости от окружения собирает разные
> >> модули. Я-то борюсь тем, что указываю все модули поимённо, но, как я
> >> заметил, многие поступают не так.
> DVL> А какая нам от этого будет польза, помимо получения удовольствия от
> DVL> процесса (if any)?
> 
> Думается ровно такая же, какой является разделение /usr/bin и /usr/lib.
> Разделение мух и котлет.

Другими словами, против перехода (возврата) на libexec возражений нет?
Все готовы усердно бороться со своими и чужими пакетами на этот предмет?

> Следующим этапом я буду предлагать не пропускать пакеты с файлами в
> /usr/libexec (в ней должны находиться исключительно каталоги, уже в
> которых файлы), зарезая из sisyphus_check.

А что, есть такие?

> IMHO все эти дополнительные якобы усложнения позволяют легче отлавливать
> неочевидные ошибки.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

On Tue, Nov 22, 2005 at 09:17:49PM +0300, Dmitry V. Levin wrote:

>> Думается ровно такая же, какой является разделение /usr/bin и /usr/lib.
>> Разделение мух и котлет.
DVL> Другими словами, против перехода (возврата) на libexec возражений нет?
DVL> Все готовы усердно бороться со своими и чужими пакетами на этот предмет?

За всех говорить не буду, но я готов.

>> Следующим этапом я буду предлагать не пропускать пакеты с файлами в
>> /usr/libexec (в ней должны находиться исключительно каталоги, уже в
>> которых файлы), зарезая из sisyphus_check.
DVL> А что, есть такие?

Думаю появятся сразу как изменится значение %_libexecdir.

-- 
С уважением, Денис

http://freesource.info


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: noarch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

On Wed, Nov 23, 2005 at 01:28:33AM +0300, Денис Смирнов wrote:
> On Tue, Nov 22, 2005 at 09:17:49PM +0300, Dmitry V. Levin wrote:
> 
> >> Думается ровно такая же, какой является разделение /usr/bin и /usr/lib.
> >> Разделение мух и котлет.
> DVL> Другими словами, против перехода (возврата) на libexec возражений нет?
> DVL> Все готовы усердно бороться со своими и чужими пакетами на этот предмет?
> 
> За всех говорить не буду, но я готов.

А остальные тоже готовы?
Вы хотя бы примерно представляете себе масштаб стихийного бедствия,
который накроет Сизиф?

Одних только noarch-пакетов, содержащих каталог /usr/lib, сейчас в Сизифе
556 штук.  Некоторые из них содержат данные (неплохо для noarch-пакетов
хранить данные в /usr/lib, верно?), некоторые - скрипты, что содержат в
/usr/lib остальные - загадка.

Сейчас соберу статистику по i586.rpm, и можно будет оценивать последствия.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]

On Wed, Nov 23, 2005 at 03:43:00AM +0300, Dmitry V. Levin wrote:
> On Wed, Nov 23, 2005 at 01:28:33AM +0300, Денис Смирнов wrote:
> > On Tue, Nov 22, 2005 at 09:17:49PM +0300, Dmitry V. Levin wrote:
> > 
> > >> Думается ровно такая же, какой является разделение /usr/bin и /usr/lib.
> > >> Разделение мух и котлет.
> > DVL> Другими словами, против перехода (возврата) на libexec возражений нет?
> > DVL> Все готовы усердно бороться со своими и чужими пакетами на этот предмет?
> > 
> > За всех говорить не буду, но я готов.
> 
> А остальные тоже готовы?
> Вы хотя бы примерно представляете себе масштаб стихийного бедствия,
> который накроет Сизиф?
> 
> Одних только noarch-пакетов, содержащих каталог /usr/lib, сейчас в Сизифе
> 556 штук.  Некоторые из них содержат данные (неплохо для noarch-пакетов
> хранить данные в /usr/lib, верно?), некоторые - скрипты, что содержат в
> /usr/lib остальные - загадка.
> 
> Сейчас соберу статистику по i586.rpm, и можно будет оценивать последствия.

Пакетов i586.rpm, содержащих только не библиотеки в каталоге /usr/lib, у
нас сейчас 2270 штук.  Если исключить пакеты, содержащие файлы меню (а они
почему-то находятся в /usr/lib/menu), то останется всего 1513 пакета,
хранящих в /usr/lib/ разные скрипты и данные, не являющиеся библиотеками.
Можно ещё найти крупные партии пакетов, хранящих нечто в /usr/lib,
например, /usr/lib/perl5.
Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB executable"
среди *.i586.rpm не менее 236 штук.

Кто будет выделять среди всей этой гущи пакетов те, которые хранят в
/usr/lib исполняемые файлы, требующие переноса в /usr/libexec?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Alexey Rusakov]

Dmitry V. Levin wrote:

>Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB executable"
>среди *.i586.rpm не менее 236 штук.
>  
>
Огласите весь список, пжалста.

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Re: libexec and x86_64

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

* Dmitry V. Levin <ldv@> [051122 21:19]:
> Другими словами, против перехода (возврата) на libexec возражений нет?
> Все готовы усердно бороться со своими и чужими пакетами на этот предмет?
xscreensaver и i386-mingw32mcvs-gcc уже побороты ;-)

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/
Tel: +7(095)504-4709, Fax: +7(095)513-1006

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Eugene Vlasov]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

Приветствую, Alexey Rusakov.
В письме от Wed, Nov 23, 2005 at 08:17:35AM +0300 вы пишете:

>>Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB 
>>executable"
>>среди *.i586.rpm не менее 236 штук.

> Огласите весь список, пжалста.

В этом списке точно присутствует emacs21 (и еще не попавший в Sisyphus
emacs22)


-- 
WBR, Eugene Vlasov        mailto:eugvv at altlinux.ru
                          JID: eugvv@jabber.ru

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libexec and x86_64: arch

[Andrei Bulava]

Dmitry V. Levin wrote:

> Пакетов i586.rpm, содержащих только не библиотеки в каталоге /usr/lib, у
> нас сейчас 2270 штук.  Если исключить пакеты, содержащие файлы меню (а они
> почему-то находятся в /usr/lib/menu), то останется всего 1513 пакета,
> хранящих в /usr/lib/ разные скрипты и данные, не являющиеся библиотеками.
> Можно ещё найти крупные партии пакетов, хранящих нечто в /usr/lib,
> например, /usr/lib/perl5.

Ага, что /usr/lib/perl5 даже удостоился отдельного упоминания в FHS
(сноска [23] в FHS-2.3).

> Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB executable"
> среди *.i586.rpm не менее 236 штук.

Читаем внимательно - выиграем обязательно:

"Applications may use a single subdirectory under /usr/lib. If an
application uses a subdirectory, all architecture-dependent data
exclusively used by the application must be placed within that
subdirectory. [23]"

Поправьте меня, если я ошибаюсь, но разве layout
/usr/lib/foo/{etc,bin,lib,sbin,share,var} из-за этой размытой
формулировки и, особенно, упоминания /usr/lib/perl5 с его (дикой) смесью
architecture-dependent и architecture-independent data (с запоздалым
упоминанием i386-linux внутри) не может считаться законным в upstream?

Практика показывает, что ещё как может :-(

То, что строчкой выше написано

"/usr/lib includes object files, libraries, and internal binaries that
are not intended to be executed directly by users or shell scripts. [22]",

а сама сноска [22] недвусмысленно говорит

"Miscellaneous architecture-independent application-specific static
files and subdirectories must be placed in /usr/share.",

upstream'у читать неинтересно, т.к. это заставит их больше думать (а
кому-то мысль об использовании autotools так и вообще ненавистна по
религиозным причинам). Раз сделано исключение для perl, то можно
продолжать пороть чушь в том же духе.

Кстати, "ELF 32-bit LSB executable" таки разрешены в /usr/lib :-\

Навскидку - LinCVS, который я когда-то так и не упаковал:

$ file /usr/share/LinCVS/lincvs.bin
/usr/share/LinCVS/lincvs.bin: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), for GNU/Linux 2.2.18, dynamically linked (uses shared
libs), stripped

Этот самый lincvs.bin и есть представитель "internal binaries that are
not intended to be executed directly by users or shell scripts", т.к.
вызывается wrapper'ом /usr/bin/lincvs.

К сожалению, дизайн LinCVS ещё тот, поэтому я не упаковал LinCVS сам
именно из-за того, что не смог оторвать "miscellaneous
architecture-independent application-specific static files and
subdirectories" в /usr/share.

IMHO, это явление - детище отображения "Program Files" на "/usr/lib" у
многих (если не у всех) приложений, разрабатываемых как
кросс-платформенные: mozilla suite, firefox, thunderbird и пр.

Так что, опять же IMHO, FHS - это сферический конь в вакууме. Начинать
вводить его в строй надо не с LinCVS и других мелочей типа mrtg ;-)
Покажите, для начала, как это будет с perl, firefox, thunderbird,
выслушайте мнение upstream по поводу вас и FHS, а уж тогда поднимайте волну.

-- 
// AB1002-UANIC

Re: [devel] libexec and x86_64

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

On Wed, Nov 23, 2005 at 11:13:59AM +0200, Andrei Bulava wrote:
[...]
> "/usr/lib includes object files, libraries, and internal binaries that
> are not intended to be executed directly by users or shell scripts. [22]",

Вообще говоря, FHS-2.3 не подразумевает наличие /usr/libexec.
Мы до сих пор обсуждали не соответствие FHS, а осмысленность и
трудоёмкость перехода.

К сожалению, стремление к осмысленности и стремление к совместимости
не всегда ведут в одном направлении.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 16611 bytes --]

On Wed, Nov 23, 2005 at 08:17:35AM +0300, Alexey Rusakov wrote:
> Dmitry V. Levin wrote:
> 
> >Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB 
> >executable"
> >среди *.i586.rpm не менее 236 штук.
> >
> Огласите весь список, пжалста.

apache /usr/lib/apache/libhttpd.ep
axiom /usr/lib/axiom/mnt/linux/bin/asq
axiom /usr/lib/axiom/mnt/linux/bin/AXIOMsys
axiom /usr/lib/axiom/mnt/linux/bin/booklet
axiom /usr/lib/axiom/mnt/linux/bin/clef
axiom /usr/lib/axiom/mnt/linux/bin/htadd
axiom /usr/lib/axiom/mnt/linux/bin/hypertex
axiom /usr/lib/axiom/mnt/linux/bin/lib/finduses
axiom /usr/lib/axiom/mnt/linux/bin/lib/markup
axiom /usr/lib/axiom/mnt/linux/bin/lib/mnt
axiom /usr/lib/axiom/mnt/linux/bin/lib/nt
axiom /usr/lib/axiom/mnt/linux/bin/sman
axiom /usr/lib/axiom/mnt/linux/bin/viewAlone
axiom /usr/lib/axiom/mnt/linux/lib/ex2ht
axiom /usr/lib/axiom/mnt/linux/lib/hthits
axiom /usr/lib/axiom/mnt/linux/lib/session
axiom /usr/lib/axiom/mnt/linux/lib/spadbuf
axiom /usr/lib/axiom/mnt/linux/lib/spadclient
axiom /usr/lib/axiom/mnt/linux/lib/view2D
axiom /usr/lib/axiom/mnt/linux/lib/view3D
axiom /usr/lib/axiom/mnt/linux/lib/viewman
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/blur
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/bmp
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/bracketing_to_hdr
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/cineon
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/collect
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/compose
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/dbbrowser
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/decompose
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/dicom
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/edge
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/fits
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/gauss_rle
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/gbr
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/gifload
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/guash
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/hdr
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/icc_examin
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/iff
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/jpeg
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/mblur
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/median
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/minimum
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/noisify
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/openexr
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/pic
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/png
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/pnm
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/psd
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/psd_save
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/rawphoto
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/rotate
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/screenshot
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/sgi
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/sharpen
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/snoise
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/sobel
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/spread
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/tga
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/tiff
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/unsharp
cinepaint /usr/lib/cinepaint/0.20-0/plug-ins/xwd
clisp /usr/lib/clisp/base/lisp.run
eclipse /usr/lib/eclipse/eclipse
emacs21-common /usr/lib/emacs/21.4/i586-alt-linux/cvtmail
emacs21-common /usr/lib/emacs/21.4/i586-alt-linux/digest-doc
emacs21-common /usr/lib/emacs/21.4/i586-alt-linux/emacsserver
emacs21-common /usr/lib/emacs/21.4/i586-alt-linux/fakemail
emacs21-common /usr/lib/emacs/21.4/i586-alt-linux/hexl
emacs21-common /usr/lib/emacs/21.4/i586-alt-linux/movemail
emacs21-common /usr/lib/emacs/21.4/i586-alt-linux/profile
emacs21-common /usr/lib/emacs/21.4/i586-alt-linux/sorted-doc
emacs21-common /usr/lib/emacs/21.4/i586-alt-linux/yow
evolution /usr/lib/evolution/2.4/evolution-addressbook-export
evolution /usr/lib/evolution/2.4/evolution-alarm-notify
evolution-exchange /usr/lib/evolution/2.4/evolution-exchange-storage
evolution /usr/lib/evolution/2.4/killev
evolution-data-server /usr/lib/evolution-data-server/camel-index-control-1.2
evolution-data-server /usr/lib/evolution-data-server/camel-lock-helper-1.2
evolution-data-server /usr/lib/evolution-data-server/evolution-data-server-1.4
evolution-webcal /usr/lib/evolution-webcal
fidogate /usr/lib/fidogate/charsetc
fidogate /usr/lib/fidogate/confval
fidogate /usr/lib/fidogate/ftn2ftn
fidogate /usr/lib/fidogate/ftn2rfc
fidogate /usr/lib/fidogate/ftnafmail
fidogate /usr/lib/fidogate/ftnafpkt
fidogate /usr/lib/fidogate/ftnflo
fidogate /usr/lib/fidogate/ftnin
fidogate /usr/lib/fidogate/ftninpost
fidogate /usr/lib/fidogate/ftnmail
fidogate /usr/lib/fidogate/ftnnews
fidogate /usr/lib/fidogate/ftnpack
fidogate /usr/lib/fidogate/ftnroute
fidogate /usr/lib/fidogate/ftntick
fidogate /usr/lib/fidogate/ftntoss
fidogate /usr/lib/fidogate/rfc2ftn
firefox /usr/lib/firefox-1.0.7/firefox-bin
firefox /usr/lib/firefox-1.0.7/mozilla-xremote-client
firefox /usr/lib/firefox-1.0.7/regchrome
firefox /usr/lib/firefox-1.0.7/regxpcom
firefox /usr/lib/firefox-1.0.7/TestGtkEmbed
firefox /usr/lib/firefox-1.0.7/xpcshell
firefox /usr/lib/firefox-1.0.7/xpicleanup
firefox /usr/lib/firefox-1.0.7/xpidl
firefox /usr/lib/firefox-1.0.7/xpt_dump
firefox /usr/lib/firefox-1.0.7/xpt_link
freeciv-server /usr/lib/freeciv/civserver
gcl /usr/lib/gcl-2.6.7/gcl-tk/gcltkaux
gcl /usr/lib/gcl-2.6.7/unixport/saved_ansi_gcl
gcl /usr/lib/gcl-2.6.7/unixport/saved_gcl
glibc-utils /usr/lib/getconf/POSIX_V6_ILP32_OFF32
glibc-utils /usr/lib/getconf/POSIX_V6_ILP32_OFFBIG
gnome-keyring /usr/lib/gnome-keyring/gnome-keyring-ask
gnome-panel /usr/lib/gnome-panel-2.0/applets/clock-applet
gnome-panel /usr/lib/gnome-panel-2.0/applets/fish-applet-2
gnome-panel /usr/lib/gnome-panel-2.0/applets/notification-area-applet
gnome-panel /usr/lib/gnome-panel-2.0/applets/wnck-applet
gnome-vfs2 /usr/lib/gnome-vfs-2.0/gnome-vfs-daemon
gnuplot /usr/lib/gnuplot/4.0/gnuplot_x11
gnustep-make-libFoundation /usr/lib/GNUstep-libFoundation/System/Library/Makefiles/ix86/linux-gnu/user_home
gnustep-make-libFoundation /usr/lib/GNUstep-libFoundation/System/Library/Makefiles/ix86/linux-gnu/which_lib
gnustep-make /usr/lib/GNUstep/System/Library/Makefiles/ix86/linux-gnu/user_home
gnustep-make /usr/lib/GNUstep/System/Library/Makefiles/ix86/linux-gnu/which_lib
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gdomap
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/autogsdoc
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/cvtenc
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/defaults
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/gdnc
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/gspath
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/make_strings
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/pl2link
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/pldes
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/plmerge
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/plparse
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/plser
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/sfparse
gnustep-base /usr/lib/GNUstep/System/Tools/ix86/linux-gnu/gnu-gnu-gnu/xmlparse
hal /usr/lib/hald-addon-acpi
hal /usr/lib/hald-addon-hid-ups
hal /usr/lib/hald-addon-pmu
hal /usr/lib/hald-addon-storage
hal /usr/lib/hald-addon-usb-csr
hal /usr/lib/hald-probe-hiddev
hal /usr/lib/hald-probe-input
hal /usr/lib/hald-probe-pc-floppy
hal /usr/lib/hald-probe-printer
hal /usr/lib/hald-probe-serial
hal /usr/lib/hald-probe-smbios
hal /usr/lib/hald-probe-storage
hal /usr/lib/hald-probe-volume
hal /usr/lib/hal.hotplug
ircservices /usr/lib/ircservices/convert-db
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/appletviewer
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/extcheck
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/idlj
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/jar
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/jarsigner
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/javac
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/javadoc
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/javah
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/javap
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/jdb
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/keytool
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/kinit
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/klist
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/ktab
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/native2ascii
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/orbd
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/policytool
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/rmic
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/rmid
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/rmiregistry
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/serialver
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/servertool
j2se1.4-blackdown-devel /usr/lib/j2se1.4-blackdown/bin/tnameserv
j2se1.4-blackdown /usr/lib/j2se1.4-blackdown/jre/bin/java
j2se1.4-blackdown /usr/lib/j2se1.4-blackdown/jre/bin/java_vm
j2se1.4-blackdown /usr/lib/j2se1.4-blackdown/jre/bin/keytool
j2se1.4-blackdown /usr/lib/j2se1.4-blackdown/jre/bin/kinit
j2se1.4-blackdown /usr/lib/j2se1.4-blackdown/jre/bin/klist
j2se1.4-blackdown /usr/lib/j2se1.4-blackdown/jre/bin/ktab
j2se1.4-blackdown /usr/lib/j2se1.4-blackdown/jre/bin/orbd
j2se1.4-blackdown /usr/lib/j2se1.4-blackdown/jre/bin/policytool
j2se1.4-blackdown /usr/lib/j2se1.4-blackdown/jre/bin/rmid
j2se1.4-blackdown /usr/lib/j2se1.4-blackdown/jre/bin/rmiregistry
j2se1.4-blackdown /usr/lib/j2se1.4-blackdown/jre/bin/servertool
j2se1.4-blackdown /usr/lib/j2se1.4-blackdown/jre/bin/tnameserv
j2se1.4-blackdown-javaws /usr/lib/j2se1.4-blackdown/jre/javaws/javawsbin
j2se1.4-blackdown /usr/lib/j2se1.4-blackdown/jre/lib/i386/awt_robot
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/appletviewer
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/extcheck
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/idlj
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/jar
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/jarsigner
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/javac
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/javadoc
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/javah
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/javap
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/jdb
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/jmap
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/keytool
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/kinit
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/klist
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/ktab
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/native2ascii
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/orbd
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/policytool
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/rmic
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/rmid
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/rmiregistry
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/serialver
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/servertool
j2se1.4-sun-devel /usr/lib/j2se1.4-sun/bin/tnameserv
j2se1.4-sun /usr/lib/j2se1.4-sun/jre/bin/java
j2se1.4-sun /usr/lib/j2se1.4-sun/jre/bin/java_vm
j2se1.4-sun /usr/lib/j2se1.4-sun/jre/bin/keytool
j2se1.4-sun /usr/lib/j2se1.4-sun/jre/bin/kinit
j2se1.4-sun /usr/lib/j2se1.4-sun/jre/bin/klist
j2se1.4-sun /usr/lib/j2se1.4-sun/jre/bin/ktab
j2se1.4-sun /usr/lib/j2se1.4-sun/jre/bin/orbd
j2se1.4-sun /usr/lib/j2se1.4-sun/jre/bin/policytool
j2se1.4-sun /usr/lib/j2se1.4-sun/jre/bin/rmid
j2se1.4-sun /usr/lib/j2se1.4-sun/jre/bin/rmiregistry
j2se1.4-sun /usr/lib/j2se1.4-sun/jre/bin/servertool
j2se1.4-sun /usr/lib/j2se1.4-sun/jre/bin/tnameserv
j2se1.4-sun-javaws /usr/lib/j2se1.4-sun/jre/javaws/javawsbin
j2se1.4-sun /usr/lib/j2se1.4-sun/jre/lib/i386/awt_robot
lbdb /usr/lib/lbdb/fetchaddr
lbdb /usr/lib/lbdb/qpto8bit
maxima-bin-clisp /usr/lib/maxima/5.9.2/binary-clisp/lisp.run
maxima-bin-gcl /usr/lib/maxima/5.9.2/binary-gcl/maxima
metacity /usr/lib/metacity/metacity-dialog
mozilla /usr/lib/mozilla/mozilla-bin
mozilla /usr/lib/mozilla/mozilla-xremote-client
mozilla /usr/lib/mozilla/regchrome
mozilla /usr/lib/mozilla/regxpcom
mozilla-devel /usr/lib/mozilla/xpcshell
mozilla /usr/lib/mozilla/xpicleanup
mozilla-devel /usr/lib/mozilla/xpidl
mozilla-devel /usr/lib/mozilla/xpt_dump
mozilla-devel /usr/lib/mozilla/xpt_link
nautilus2-cd-burner /usr/lib/nautilus-2.0/components/mapping-daemon
openoffice.org2 /usr/lib/OpenOffice.org2/program/configimport.bin
openoffice.org2-gnome /usr/lib/OpenOffice.org2/program/gnome-open-url.bin
openoffice.org2 /usr/lib/OpenOffice.org2/program/javaldx
openoffice.org2 /usr/lib/OpenOffice.org2/program/nsplugin
openoffice.org2 /usr/lib/OpenOffice.org2/program/pkgchk.bin
openoffice.org2 /usr/lib/OpenOffice.org2/program/pluginapp.bin
openoffice.org2 /usr/lib/OpenOffice.org2/program/setofficelang.bin
openoffice.org2 /usr/lib/OpenOffice.org2/program/soffice.bin
openoffice.org2 /usr/lib/OpenOffice.org2/program/spadmin.bin
openoffice.org2 /usr/lib/OpenOffice.org2/program/testtool.bin
openoffice.org2 /usr/lib/OpenOffice.org2/program/uno.bin
openoffice.org2 /usr/lib/OpenOffice.org2/program/unopkg.bin
postfix /usr/lib/postfix/anvil
postfix /usr/lib/postfix/bounce
postfix /usr/lib/postfix/cleanup
postfix /usr/lib/postfix/discard
postfix /usr/lib/postfix/error
postfix /usr/lib/postfix/flush
postfix /usr/lib/postfix/lmtp-std
postfix-tls /usr/lib/postfix/lmtp-tls
postfix /usr/lib/postfix/local
postfix /usr/lib/postfix/master
postfix /usr/lib/postfix/pickup
postfix /usr/lib/postfix/pipe
postfix /usr/lib/postfix/proxymap
postfix /usr/lib/postfix/qmgr
postfix /usr/lib/postfix/qmqpd
postfix /usr/lib/postfix/scache
postfix /usr/lib/postfix/showq
postfix /usr/lib/postfix/smtpd-std
postfix-tls /usr/lib/postfix/smtpd-tls
postfix /usr/lib/postfix/smtp-std
postfix-tls /usr/lib/postfix/smtp-tls
postfix /usr/lib/postfix/spawn
postfix-tls /usr/lib/postfix/tlsmgr
postfix /usr/lib/postfix/trivial-rewrite
postfix /usr/lib/postfix/verify
postfix /usr/lib/postfix/virtual
qt4-assistant /usr/lib/qt4/bin/assistant
qt4-designer /usr/lib/qt4/bin/designer
qt4-designer /usr/lib/qt4/bin/linguist
libqt4-devel /usr/lib/qt4/bin/lrelease
libqt4-devel /usr/lib/qt4/bin/lupdate
libqt4-devel /usr/lib/qt4/bin/moc
libqt4-devel /usr/lib/qt4/bin/qm2ts
libqt4-devel /usr/lib/qt4/bin/qmake
libqt4-devel /usr/lib/qt4/bin/qt3to4
libqt4-qt3support /usr/lib/qt4/bin/qtconfig
libqt4-devel /usr/lib/qt4/bin/rcc
libqt4-devel /usr/lib/qt4/bin/uic3
gnome-applets-extra-quick-lounge /usr/lib/quick-lounge/quick-lounge-applet
rpm-build /usr/lib/rpm/filesize
rpm /usr/lib/rpm/pdeath_execute
rpm-build /usr/lib/rpm/relative
rpm-build /usr/lib/rpm/rpmb
rpm /usr/lib/rpm/rpmd
rpm /usr/lib/rpm/rpmi
rpm /usr/lib/rpm/rpmk
rpm /usr/lib/rpm/rpmq
squid-cachemgr /usr/lib/squid/cachemgr.cgi
squid-helpers /usr/lib/squid/digest_pw_auth
squid-server /usr/lib/squid/diskd
squid-helpers /usr/lib/squid/fakeauth_auth
squid-helpers /usr/lib/squid/getpwname_auth
squid-helpers /usr/lib/squid/ip_user_check
squid-helpers /usr/lib/squid/msnt_auth
squid-helpers /usr/lib/squid/ncsa_auth
squid-helpers /usr/lib/squid/ntlm_auth
squid-helpers /usr/lib/squid/sasl_auth
squid-helpers /usr/lib/squid/squid_ldap_auth
squid-helpers /usr/lib/squid/squid_ldap_group
squid-helpers /usr/lib/squid/squid_unix_group
squid-server /usr/lib/squid/unlinkd
squid-helpers /usr/lib/squid/wb_auth
squid-helpers /usr/lib/squid/wb_group
squid-helpers /usr/lib/squid/wb_ntlmauth
squid-helpers /usr/lib/squid/yp_auth
TeXmacs /usr/lib/TeXmacs/bin/maple_filter
TeXmacs /usr/lib/TeXmacs/bin/maple_in_filter
TeXmacs /usr/lib/TeXmacs/bin/maxima_filter
TeXmacs /usr/lib/TeXmacs/bin/reduce_filter
TeXmacs /usr/lib/TeXmacs/bin/texmacs.bin
TeXmacs /usr/lib/TeXmacs/bin/tm_axiom
TeXmacs /usr/lib/TeXmacs/bin/tm_graphviz
TeXmacs /usr/lib/TeXmacs/bin/tm_shell
xfce4-session /usr/lib/xfsm-shutdown-helper


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Dmitry V. Levin]

[-- Attachment #1.1: Type: text/plain, Size: 363 bytes --]

On Wed, Nov 23, 2005 at 08:17:35AM +0300, Alexey Rusakov wrote:
> Dmitry V. Levin wrote:
> 
> >Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB 
> >executable"
> >среди *.i586.rpm не менее 236 штук.

Прежняя версия была основана на неполных данных.  Список пакетов и
файлов в них, претендующий на полноту, пожат и приложен.


-- 
ldv

[-- Attachment #1.2: usrlibelfexec.list.gz --]
[-- Type: application/x-gzip, Size: 9696 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Alexander Bokovoy]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

On Wed, Nov 23, 2005 at 05:17:31AM +0300, Dmitry V. Levin wrote:
> > Сейчас соберу статистику по i586.rpm, и можно будет оценивать последствия.
> 
> Пакетов i586.rpm, содержащих только не библиотеки в каталоге /usr/lib, у
> нас сейчас 2270 штук.  Если исключить пакеты, содержащие файлы меню (а они
> почему-то находятся в /usr/lib/menu), то останется всего 1513 пакета,
> хранящих в /usr/lib/ разные скрипты и данные, не являющиеся библиотеками.
> Можно ещё найти крупные партии пакетов, хранящих нечто в /usr/lib,
> например, /usr/lib/perl5.
> Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB executable"
> среди *.i586.rpm не менее 236 штук.
> 
> Кто будет выделять среди всей этой гущи пакетов те, которые хранят в
> /usr/lib исполняемые файлы, требующие переноса в /usr/libexec?
Мне интересно, а имеет ли смысл вообще оживлять /usr/libexec? Согласно
последним замечаниям в git@, когда пытались скрипты-утилиты куда-то
спрятать, libexec вообще сущность умирающая. Заявителей подобного было
довольно много и все как на подбор из мейнтейнеров дистрибутивов и
компонент ядра.

Я задумался...

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Igor Zubkov]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

В сообщении от Среда, 23-Ноя-2005 04:17 Dmitry V. Levin написал(a):
>  Если исключить пакеты, содержащие файлы меню (а они
> почему-то находятся в /usr/lib/menu), то останется всего 1513 пакета,
> хранящих в /usr/lib/ разные скрипты и данные, не являющиеся библиотеками.

Мне вот давно интересно, а почему именно /usr/lib/menu/, а не /usr/share/menu?

Ответ, в стиле, так сделано в debian из которого мы взяли menu мне не 
интересен.

-- 
http://www.livejournal.com/users/icesik/7614.html
http://www.livejournal.com/users/icesik/7393.html
http://www.livejournal.com/users/icesik/7024.html

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [devel] Re: libexec and x86_64

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]

On Thu, Nov 24, 2005 at 01:12:24AM +0300, Alexander Bokovoy wrote:
> On Wed, Nov 23, 2005 at 05:17:31AM +0300, Dmitry V. Levin wrote:
> > > Сейчас соберу статистику по i586.rpm, и можно будет оценивать последствия.
> > 
> > Пакетов i586.rpm, содержащих только не библиотеки в каталоге /usr/lib, у
> > нас сейчас 2270 штук.  Если исключить пакеты, содержащие файлы меню (а они
> > почему-то находятся в /usr/lib/menu), то останется всего 1513 пакета,
> > хранящих в /usr/lib/ разные скрипты и данные, не являющиеся библиотеками.
> > Можно ещё найти крупные партии пакетов, хранящих нечто в /usr/lib,
> > например, /usr/lib/perl5.
> > Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB executable"
> > среди *.i586.rpm не менее 236 штук.
> > 
> > Кто будет выделять среди всей этой гущи пакетов те, которые хранят в
> > /usr/lib исполняемые файлы, требующие переноса в /usr/libexec?
> Мне интересно, а имеет ли смысл вообще оживлять /usr/libexec? Согласно
> последним замечаниям в git@, когда пытались скрипты-утилиты куда-то
> спрятать, libexec вообще сущность умирающая. Заявителей подобного было
> довольно много и все как на подбор из мейнтейнеров дистрибутивов и
> компонент ядра.

Нет, libexec сущность не умирающая, а по сути не возникшая в дистрибутивах
GNU/*/Linux.  В BSD libexec живёт и процветает.  Вот только нужно ли нам
подобное внедрять?  Я не уверен, поскольку хлопот будет много, а
потенциальные выгоды призрачны.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: noarch

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

On Wed, Nov 23, 2005 at 03:43:00AM +0300, Dmitry V. Levin wrote:

DVL> А остальные тоже готовы?
DVL> Вы хотя бы примерно представляете себе масштаб стихийного бедствия,
DVL> который накроет Сизиф?

От смены значения макроса %_libexec?

Нет, не представляю.

Я не предлагаю в ближайшем времени _требовать_ корректного размещения
файлов, однако _предоставить возможность_ желающим поступить правильно
мантейнерам стоит.

Второй этап -- робот-QA, который сможет указать мантейнерам на их ошибки.

А требовать можно не ранее чем через год.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Если я не вернyсь - считайте меня программистом.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64

[Vadim V. Zhytnikov]

Dmitry V. Levin пишет:

>>Мне интересно, а имеет ли смысл вообще оживлять /usr/libexec? Согласно
>>последним замечаниям в git@, когда пытались скрипты-утилиты куда-то
>>спрятать, libexec вообще сущность умирающая. Заявителей подобного было
>>довольно много и все как на подбор из мейнтейнеров дистрибутивов и
>>компонент ядра.
> 
> 
> Нет, libexec сущность не умирающая, а по сути не возникшая в дистрибутивах
> GNU/*/Linux.  В BSD libexec живёт и процветает.  Вот только нужно ли нам
> подобное внедрять?  Я не уверен, поскольку хлопот будет много, а
> потенциальные выгоды призрачны.
> 

А есть ли другие Linux distro внедряющие/вендрившие libexec?
Если нет (а это, кажется, именно так), то я бы не стал.

Кроме того FHS - какой-никакой но всё-таки стандарт.

Зачем становиться отличными от всех и от всего если
а) это потребует тучу усилий
б) выгоды не вполне ясны

-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

[devel] Re: libexec and x86_64: arch

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 617 bytes --]

On Wed, Nov 23, 2005 at 04:00:57PM +0300, Dmitry V. Levin wrote:
> > >Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit
> > >LSB executable" среди *.i586.rpm не менее 236 штук.
> > Огласите весь список, пжалста.
> apache /usr/lib/apache/libhttpd.ep

Кстати.  А этот самый shared core ещё актуален?  Если только ради
Kylix во времена 2.0 делался -- то есть подозрение, что эта
причина померла, других не знаю, а "сапог в бою надёжней" мне
как-то милее "работает -- не трогай" _в данном случае_.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: libexec and x86_64: arch

[Michael Shigorin]

On Thu, Nov 24, 2005 at 12:29:26AM +0300, Dmitry V. Levin wrote:
> Прежняя версия была основана на неполных данных.  Список
> пакетов и файлов в них, претендующий на полноту, пожат и
> приложен.

[1321 fewer lines]

Боюсь, страшновато.  Не за свои, их полтора зацепило...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] Re: libexec and x86_64: arch

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 274 bytes --]

On Thu, Nov 24, 2005 at 12:15:12AM +0200, Igor Zubkov wrote:
> Ответ, в стиле, так сделано в debian из которого мы взяли menu
> мне не интересен.

Ты знал, ты знал :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

On Thu, Nov 24, 2005 at 08:24:03AM +0300, Vadim V. Zhytnikov wrote:

VVZ> А есть ли другие Linux distro внедряющие/вендрившие libexec?
VVZ> Если нет (а это, кажется, именно так), то я бы не стал.

 - больше нет Linux distro внедривших hasher и добившихся такой же
   целостности репозитория как в ALT;
 - больше (AFAIR) нет дистрибутива (разве что openwall?), где не-PIC код в
   библиотеках является критической багой, не дающей собрать пакет;

Ну и т.д.

VVZ> Кроме того FHS - какой-никакой но всё-таки стандарт.
VVZ> Зачем становиться отличными от всех и от всего если
VVZ> а) это потребует тучу усилий
VVZ> б) выгоды не вполне ясны

Выгоды от целостности репозитория тоже не вполне ясны.

Качество в мелочах проявляется.

-- 
С уважением, Денис

http://freesource.info


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64

[Vadim V. Zhytnikov]

Денис Смирнов пишет:
> On Thu, Nov 24, 2005 at 08:24:03AM +0300, Vadim V. Zhytnikov wrote:
> 
> VVZ> А есть ли другие Linux distro внедряющие/вендрившие libexec?
> VVZ> Если нет (а это, кажется, именно так), то я бы не стал.
> 
>  - больше нет Linux distro внедривших hasher и добившихся такой же
>    целостности репозитория как в ALT;
>  - больше (AFAIR) нет дистрибутива (разве что openwall?), где не-PIC код в
>    библиотеках является критической багой, не дающей собрать пакет;
> 

Это не имеет отношения к существу _конкретного_ _рассматриваемого_ 
вопроса.  Я не пытаюсь сказать -- "давайте сделаем всё как у всех и 
будет нам счастье ...".  Я пытаюсь взвесить pro и contra по поводу
libexec.  Новый элемент "несовместимости со всеми" должен быть чем-то
оправдан.

> 
> VVZ> Кроме того FHS - какой-никакой но всё-таки стандарт.
> VVZ> Зачем становиться отличными от всех и от всего если
> VVZ> а) это потребует тучу усилий
> VVZ> б) выгоды не вполне ясны
> 
> Выгоды от целостности репозитория тоже не вполне ясны.
>

Да ну?  Совершенно ясны!

> Качество в мелочах проявляется.

Собственно я опасаюсь, что качества введение libexec
не очень добавит, а добавит только работы мантейнерам
тех пакетов, которые (пакеты) не хотят ничего знать об
libexec.  Работы, повторяющейся с каждым новым
релизом...


-- 
      Vadim V. Zhytnikov

       <vvzhy@mail.ru>
      <vvzhy@netorn.ru>

Re: [devel] Re: libexec and x86_64: arch

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Thu, Nov 24, 2005 at 12:29:26AM +0300, Dmitry V. Levin wrote:
> Прежняя версия была основана на неполных данных.  Список пакетов и
> файлов в них, претендующий на полноту, пожат и приложен.
Интересно, сколько народу (спеков, тарболлов и юзеров) не сможет найти qt
в /usr/libexec/qt[34] ?
Только у меня в 4 пакетах пробито /usr/lib :( (я знаю, что это баг).

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

В Гераклы (это по части конюшен) не гожусь, поэтому в лучших альтовских
традициях изобретаю совершенно свободное от недостатков предшественников
колесо.
		-- mike in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Alexey Voinov]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

Dmitry V. Levin wrote
> On Wed, Nov 23, 2005 at 08:17:35AM +0300, Alexey Rusakov wrote:
> > Dmitry V. Levin wrote:
> > 
> > >Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB 
> > >executable"
> > >среди *.i586.rpm не менее 236 штук.
> 
> Прежняя версия была основана на неполных данных.  Список пакетов и
> файлов в них, претендующий на полноту, пожат и приложен.
Делать-то с ними чего? Переехать в libexec?

-- 
Best Regards!
Alexey Voinov
	     
voins@voins.program.ru
voins@altlinux.ru


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

On Thu, Nov 24, 2005 at 08:36:41PM +0300, Alexey Voinov wrote:
> Dmitry V. Levin wrote
> > On Wed, Nov 23, 2005 at 08:17:35AM +0300, Alexey Rusakov wrote:
> > > Dmitry V. Levin wrote:
> > > 
> > > >Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB 
> > > >executable"
> > > >среди *.i586.rpm не менее 236 штук.
> > 
> > Прежняя версия была основана на неполных данных.  Список пакетов и
> > файлов в них, претендующий на полноту, пожат и приложен.
> Делать-то с ними чего? Переехать в libexec?

Да нет, просто посмотреть. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Genix]

Andrey Rahmatullin wrote:

> Интересно, сколько народу (спеков, тарболлов и юзеров) не сможет найти qt
> в /usr/libexec/qt[34] ?
> Только у меня в 4 пакетах пробито /usr/lib :( (я знаю, что это баг).

подсмотрел у кого-то такую штуку:
unset QTDIR || : ; . /etc/profile.d/qt3dir.sh



-- 
У каждого в башке свои тараканы...

Re: [devel] Re: libexec and x86_64: arch

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

On Thu, Nov 24, 2005 at 09:41:05PM +0300, Genix wrote:
> подсмотрел у кого-то такую штуку:
> unset QTDIR || : ; . /etc/profile.d/qt3dir.sh
Да знаю я.
Ладно, пойду пофикшу в спеках в CVS, но отдельные сборки заливать влом.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> python-module-PyQt-examples-3.14.1-alt1.1.1.1.1
Это потому, что пакет пересобирается роботом при каждом новом
релизе QT, а робот просто добавляет .1 к строке релиза.
		-- eugvv in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

В Чтв, 24/11/2005 в 20:49 +0300, Dmitry V. Levin пишет:
> On Thu, Nov 24, 2005 at 08:36:41PM +0300, Alexey Voinov wrote:
> > Dmitry V. Levin wrote
> > > On Wed, Nov 23, 2005 at 08:17:35AM +0300, Alexey Rusakov wrote:
> > > > Dmitry V. Levin wrote:
> > > > 
> > > > >Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB 
> > > > >executable"
> > > > >среди *.i586.rpm не менее 236 штук.
> > > 
> > > Прежняя версия была основана на неполных данных.  Список пакетов и
> > > файлов в них, претендующий на полноту, пожат и приложен.
> > Делать-то с ними чего? Переехать в libexec?
> 
> Да нет, просто посмотреть. :)

Посмотрел. Многие приложения не делают различий между исполняемыми
файлами и DSO-модулями, сваливая их в одно место в $libdir и называя
application directory. JDK, например, не получится развести, он живет в
едином $JAVA_HOME.


[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64

[Alexander Bokovoy]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

On Thu, Nov 24, 2005 at 01:21:20AM +0300, Dmitry V. Levin wrote:
> > Мне интересно, а имеет ли смысл вообще оживлять /usr/libexec? Согласно
> > последним замечаниям в git@, когда пытались скрипты-утилиты куда-то
> > спрятать, libexec вообще сущность умирающая. Заявителей подобного было
> > довольно много и все как на подбор из мейнтейнеров дистрибутивов и
> > компонент ядра.
> 
> Нет, libexec сущность не умирающая, а по сути не возникшая в дистрибутивах
> GNU/*/Linux.  В BSD libexec живёт и процветает.  Вот только нужно ли нам
> подобное внедрять?  Я не уверен, поскольку хлопот будет много, а
> потенциальные выгоды призрачны.
Речь шла о FHS и фактическом неиспользовании libexec в его рамках,
несмотря на формальное наличие. Это и называлось умирающим.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Anton D. Kachalov]

On Thu, Nov 24, 2005 at 09:41:05PM +0300, Genix wrote:
> Andrey Rahmatullin wrote:
> 
> >Интересно, сколько народу (спеков, тарболлов и юзеров) не сможет найти qt
> >в /usr/libexec/qt[34] ?
> >Только у меня в 4 пакетах пробито /usr/lib :( (я знаю, что это баг).
> подсмотрел у кого-то такую штуку:
> unset QTDIR || : ; . /etc/profile.d/qt3dir.sh
Это хак. Чем таким libqt3-devel отличается от php-devel? В последнем есть
rpm-макросы специально под такие случаи.

2Zerg: очень хотелось бы уже к началу следующей недели иметь в _Сизифе_ QT
с rpm'ми макросами.
Бага: #8559 висит.

--
mouse

Re: [devel] Re: libexec and x86_64: arch

[Anton D. Kachalov]

On Fri, Nov 25, 2005 at 12:10:21AM +0500, Andrey Rahmatullin wrote:
> On Thu, Nov 24, 2005 at 09:41:05PM +0300, Genix wrote:
> > подсмотрел у кого-то такую штуку:
> > unset QTDIR || : ; . /etc/profile.d/qt3dir.sh
> Да знаю я.
> Ладно, пойду пофикшу в спеках в CVS, но отдельные сборки заливать влом.
Лучше так не делать. А подождать появления qt3 с нормальными макросами для
rpm.

--
mouse

[devel] Re: Re: libexec and x86_64: arch

[Anton Farygin]

On Fri, 25 Nov 2005 13:00:21 +0300, Anton D. Kachalov wrote:

> On Thu, Nov 24, 2005 at 09:41:05PM +0300, Genix wrote:
>> Andrey Rahmatullin wrote:
>> 
>> >Интересно, сколько народу (спеков,
>> >тарболлов и юзеров) не сможет найти qt в
>> >/usr/libexec/qt[34] ?
>> >Только у меня в 4 пакетах пробито /usr/lib :(
>> >(я знаю, что это баг).
>> подсмотрел у кого-то такую штуку: unset QTDIR
>> || : ; . /etc/profile.d/qt3dir.sh
> Это хак. Чем таким libqt3-devel отличается от
> php-devel? В последнем есть rpm-макросы
> специально под такие случаи.
> 
> 2Zerg: очень хотелось бы уже к началу
> следующей недели иметь в _Сизифе_ QT с
> rpm'ми макросами.
> Бага: #8559 висит.

К началу не получится ;-)

Zerg в отпуске.

Мне кажется, что он не сильно будет
возражать против NMU, тем более
предложенный мной Draft Policy это вроде как разрешает ;-)

Rgds,
Rider

Re: [devel] Re: libexec and x86_64

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On Thu, Nov 24, 2005 at 06:06:21PM +0300, Vadim V. Zhytnikov wrote:

VVZ> Собственно я опасаюсь, что качества введение libexec
VVZ> не очень добавит, а добавит только работы мантейнерам
VVZ> тех пакетов, которые (пакеты) не хотят ничего знать об
VVZ> libexec.  Работы, повторяющейся с каждым новым
VVZ> релизом...

Никто не заставляет мантейнера использовать libexec (и вообще макрос
%_libexecdir). Но дать ему возможность собрать пакет грамотно -- стоит.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Она сопротивлялась, но я её всё-таки закрою.
		-- avm in #7518

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

On Thu, Nov 24, 2005 at 01:13:26PM +0200, Michael Shigorin wrote:

> > >>Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit
> > >>LSB executable" среди *.i586.rpm не менее 236 штук.
> >> Огласите весь список, пжалста.
>> apache /usr/lib/apache/libhttpd.ep
MS> Кстати.  А этот самый shared core ещё актуален?  Если только ради
MS> Kylix во времена 2.0 делался -- то есть подозрение, что эта
MS> причина померла, других не знаю, а "сапог в бою надёжней" мне
MS> как-то милее "работает -- не трогай" _в данном случае_.

Помнится были какие-то ещё причины.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
ok, в следующей сборке "задним числом" добавим в changelog.
		-- ldv in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] apache: shared core?

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

On Sat, Nov 26, 2005 at 11:45:16PM +0300, Денис Смирнов wrote:
> > > >>Пакетов, содержащих в недрах /usr/lib файлы типа "ELF
> > > >>32-bit LSB executable" среди *.i586.rpm не менее 236
> > > >>штук.
> > >> Огласите весь список, пжалста.
> >> apache /usr/lib/apache/libhttpd.ep
> MS> Кстати.  А этот самый shared core ещё актуален?  Если только ради
> MS> Kylix во времена 2.0 делался -- то есть подозрение, что эта
> MS> причина померла, других не знаю, а "сапог в бою надёжней" мне
> MS> как-то милее "работает -- не трогай" _в данном случае_.
> Помнится были какие-то ещё причины.

Нашёл вот что:
http://lists.altlinux.ru/pipermail/sisyphus/2004-February/036632.html
http://lists.altlinux.ru/pipermail/sisyphus/2004-February/036639.html
http://lists.altlinux.ru/pipermail/sisyphus/2004-February/036643.html

PS: сборка с SHARED_CORE происходит с 1.3.23rusPL30.11-alt3 от 21
февраля 2002 года и исключительно из-за покойного Kylix.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Sergey V Turchin]

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

On Wednesday 23 November 2005 05:17, Dmitry V. Levin wrote:

[...]

> содержащие файлы меню (а они почему-то находятся в
> /usr/lib/menu)
Дык, поменяй %_menudir на /usr/share/menu

[...]

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [devel] Re: Re: libexec and x86_64: arch

[Sergey V Turchin]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

On Friday 25 November 2005 16:56, Anton Farygin wrote:

[...]

> Мне кажется, что он не сильно будет
> возражать против NMU
Не буду. У меня это еще до отпуска появилось, но уже в qt-3.3.5.
Закончу последний эксперимент и выложу.

> , тем более 
> предложенный мной Draft Policy это вроде как разрешает ;-)
В нем надо запретить NMU без высылания патчей мантейнеру ;-)

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [devel] Re: Re: libexec and x86_64: arch

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 179 bytes --]

Sergey V Turchin пишет:

>>, тем более 
>>предложенный мной Draft Policy это вроде как разрешает ;-)
> 
> В нем надо запретить NMU без высылания патчей мантейнеру ;-)
+1


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: Re: libexec and x86_64: arch

[Anton D. Kachalov]

On Mon, Nov 28, 2005 at 04:47:40PM +0800, Ivan Fedorov wrote:
> Sergey V Turchin пишет:
> 
> >>, тем более 
> >>предложенный мной Draft Policy это вроде как разрешает ;-)
> > 
> > В нем надо запретить NMU без высылания патчей мантейнеру ;-)
> +1
Патчи не самому мантейнеру,а через bugzilla.

--
mouse

Re: [devel] Re: libexec and x86_64

[Stanislav Ievlev]

On Thu, Nov 24, 2005 at 01:21:20AM +0300, Dmitry V. Levin wrote:
> On Thu, Nov 24, 2005 at 01:12:24AM +0300, Alexander Bokovoy wrote:
> > On Wed, Nov 23, 2005 at 05:17:31AM +0300, Dmitry V. Levin wrote:
> > > > Сейчас соберу статистику по i586.rpm, и можно будет оценивать последствия.
> > > 
> > > Пакетов i586.rpm, содержащих только не библиотеки в каталоге /usr/lib, у
> > > нас сейчас 2270 штук.  Если исключить пакеты, содержащие файлы меню (а они
> > > почему-то находятся в /usr/lib/menu), то останется всего 1513 пакета,
> > > хранящих в /usr/lib/ разные скрипты и данные, не являющиеся библиотеками.
> > > Можно ещё найти крупные партии пакетов, хранящих нечто в /usr/lib,
> > > например, /usr/lib/perl5.
> > > Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB executable"
> > > среди *.i586.rpm не менее 236 штук.
> > > 
> > > Кто будет выделять среди всей этой гущи пакетов те, которые хранят в
> > > /usr/lib исполняемые файлы, требующие переноса в /usr/libexec?
> > Мне интересно, а имеет ли смысл вообще оживлять /usr/libexec? Согласно
> > последним замечаниям в git@, когда пытались скрипты-утилиты куда-то
> > спрятать, libexec вообще сущность умирающая. Заявителей подобного было
> > довольно много и все как на подбор из мейнтейнеров дистрибутивов и
> > компонент ядра.
> 
> Нет, libexec сущность не умирающая, а по сути не возникшая в дистрибутивах
> GNU/*/Linux.  В BSD libexec живёт и процветает.  Вот только нужно ли нам
> подобное внедрять?  Я не уверен, поскольку хлопот будет много, а
> потенциальные выгоды призрачны.
Просветите меня. Что мне делать с alterator.
Там бакенды лежат сейчас в /usr/lib/alterator/backend.
backend'ы могут быть как архитектурно-независимыми, так из зависимыми.

С одной стороны не стоит делать /usr/libexec/alterator, ибо традиционно
предполагалось что в libexec будут только скрипты (например для cgi), а тут могут быть и
бинари тоже.
С другой стороны не стоит делать arch пакеты только из-за /usr/lib.
Сейчас у меня также как и в perl просто гвоздями прибитый /usr/lib -
почему-то мне кажется это самым простым и понятным решением. И для arch и
для noarch модулей.

P.S. FHS как я понял отказался от /usr/libexec для скриптов в пользу /srv.

--
Стас.

Re: [devel] Re: Re: libexec and x86_64: arch

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 419 bytes --]

Anton D. Kachalov пишет:
> On Mon, Nov 28, 2005 at 04:47:40PM +0800, Ivan Fedorov wrote:
> 
>>Sergey V Turchin пишет:
>>
>>
>>>>, тем более 
>>>>предложенный мной Draft Policy это вроде как разрешает ;-)
>>>
>>>В нем надо запретить NMU без высылания патчей мантейнеру ;-)
>>
>>+1
> 
> Патчи не самому мантейнеру,а через bugzilla.
согласен.

мантейнер может быть недоступен... а может быть команда...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: libexec and x86_64: arch

[Igor Vlasenko]

> > Dmitry V. Levin wrote:
> > 
> > >Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB 
> > >executable"
> > >среди *.i586.rpm не менее 236 штук.
> > >
> > Огласите весь список, пжалста.

Таких списков у нас много - elfs в lib, share, ... misaligned-bugs ...
А удобного механизма доступа к ним нет.

Насколько бы удобнее было бы 
1) иметь их доступными полностью через html
2) внедрить на них ссылки в Proteus из пакета - автора,
что-то вроде "Ваши пакеты отмечены такими-то роботами"
И обсуждения такого рода были бы гораздо более конструктивными.

-- 

Dr. Igor Vlasenko
--------------------
Topology Departament
Institute of Math
Kiev, Ukraine

Re: [devel] libexec and x86_64: arch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

On Thu, Nov 24, 2005 at 12:29:26AM +0300, Dmitry V. Levin wrote:
> > >Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB 
> > >executable"
> > >среди *.i586.rpm не менее 236 штук.

> R-base	/usr/lib/R/bin/R.bin

Совсем плохо будет, если этот исполняемый файл останется в /usr/lib/R?
Точнее, в %_libdir/R.  Или уже проехали?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libexec and x86_64: arch

[Anton Farygin]

Alexey Tourbin wrote:
> On Thu, Nov 24, 2005 at 12:29:26AM +0300, Dmitry V. Levin wrote:
>>>> Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB 
>>>> executable"
>>>> среди *.i586.rpm не менее 236 штук.
> 
>> R-base	/usr/lib/R/bin/R.bin
> 
> Совсем плохо будет, если этот исполняемый файл останется в /usr/lib/R?
> Точнее, в %_libdir/R.  Или уже проехали?
> 

Правильнее наверное его укладывать в libexec

но наверное это пофиг ;)

Вообще целью разнесения исполняемых файлов от библиотек в итоге должно 
стать biarch - возможнось одновременной установки библиотке как x86_64, 
так и x86.

Rgds,
Rider

Re: [devel] libexec and x86_64: arch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On Wed, Apr 26, 2006 at 11:23:46PM +0400, Anton Farygin wrote:
> Alexey Tourbin wrote:
> > On Thu, Nov 24, 2005 at 12:29:26AM +0300, Dmitry V. Levin wrote:
> >>>> Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB 
> >>>> executable"
> >>>> среди *.i586.rpm не менее 236 штук.
> > 
> >> R-base	/usr/lib/R/bin/R.bin
> > 
> > Совсем плохо будет, если этот исполняемый файл останется в /usr/lib/R?
> > Точнее, в %_libdir/R.  Или уже проехали?
> > 
> 
> Правильнее наверное его укладывать в libexec
> 
> но наверное это пофиг ;)
> 
> Вообще целью разнесения исполняемых файлов от библиотек в итоге должно 
> стать biarch - возможнось одновременной установки библиотке как x86_64, 
> так и x86.

В случае с R-base это точно не актуально.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] libexec and x86_64: arch

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

On Wed, Nov 23, 2005 at 11:13:59AM +0200, Andrei Bulava wrote:
> Поправьте меня, если я ошибаюсь, но разве layout
> /usr/lib/foo/{etc,bin,lib,sbin,share,var} из-за этой размытой
> формулировки и, особенно, упоминания /usr/lib/perl5 с его (дикой) смесью
> architecture-dependent и architecture-independent data (с запоздалым
> упоминанием i386-linux внутри) не может считаться законным в upstream?

С выходом более более новой версии перла (допустим, 5.10) структура
перловх каталогов должна поменяться:

/usr/lib/perl5/i386-linux -> /usr/lib/perl5
/usr/lib/perl5 -> /usr/share/perl5

Это можно сделать уже и сейчас.  В дебиане так сделано.  Просто сейчас
не хочется пересобирать стот тыщь мильёнов пакетов и ставить им
зависимости на новый каталог.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]