[devel] libexec and x86_64

[devel] libexec and x86_64

[Vadim V. Zhytnikov]

Добрый день!

Не секрет, что некоторые пакеты упорно
пытаются ставить бинарники в /usr/libexec.
Для ix86 мы их перенаправляем в /usr/lib
установкой %_libexecdir=/usr/lib и здесь
всё ОК.  Но для x86_64 в macros видим

%_libexecdir		/usr/lib
%_libdir		/usr/lib64

Не бага ли это?  Мне кажется, что должно быть

%_libexecdir		/usr/lib64

Да, FHS libexec не определяет и не трактует, но,
насколько я понимаю, эта директория всё-таки
предназначена для arch-зависимых данных.

Мнения?

Хочу gnuplot для для x86_64, а он ставит
gnuplot_x11 в libexec :-(
Что патчить - gnuplot или rpm?

-- 
      Vadim V. Zhytnikov

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

Re: [devel] libexec and x86_64

[Dmitry V. Levin]

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

On Thu, Oct 27, 2005 at 12:38:18PM +0300, Vadim V. Zhytnikov wrote:
> Не секрет, что некоторые пакеты упорно
> пытаются ставить бинарники в /usr/libexec.
> Для ix86 мы их перенаправляем в /usr/lib
> установкой %_libexecdir=/usr/lib и здесь
> всё ОК.  Но для x86_64 в macros видим
> 
> %_libexecdir		/usr/lib
> %_libdir		/usr/lib64
> 
> Не бага ли это?

Скорее всего, нет.

> Мне кажется, что должно быть
> 
> %_libexecdir		/usr/lib64

Если бы не проблемы переезда, то я бы давно уже вернул %_libexecdir в
/usr/libexec.

> Да, FHS libexec не определяет и не трактует, но,
> насколько я понимаю, эта директория всё-таки
> предназначена для arch-зависимых данных.

Да, конечно.
Насколько я понимаю, каталог libexec предназначен для arch-зависимых
исполняемых файлов, в отличие от lib, предназначенного для arch-зависимых
неисполняемых файлов.  executables vs libraries.

> Хочу gnuplot для для x86_64, а он ставит
> gnuplot_x11 в libexec :-(
> Что патчить - gnuplot или rpm?

Стоит пропатчить gnuplot, чтобы он использовал %_libexecdir.


-- 
ldv

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

Re: [devel] libexec and x86_64

[Dmitry V. Levin]

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

On Thu, Oct 27, 2005 at 10:50:01PM +0300, Vadim V. Zhytnikov wrote:
[...]
> >Стоит пропатчить gnuplot, чтобы он использовал %_libexecdir.
> 
> Так он его как-раз его и использует.  Он кладёт исполняемый ELF
> gnuplot_x11 в libexec.  Поскольку у нас %_libexecdir на
> x86_64 устеновлен /usr/lib, то получаем
> 
> /usr/lib/gnuplot/gnuplot_x11
> 
> а должно быть
> 
> /usr/lib64/gnuplot/gnuplot_x11

А почему должно быть /usr/lib64/gnuplot/gnuplot_x11 а не
/usr/lib/gnuplot/gnuplot_x11 или /usr/libexec/gnuplot/gnuplot_x11?


-- 
ldv

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

Re: [devel] libexec and x86_64

[Dmitry V. Levin]

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

On Thu, Oct 27, 2005 at 11:11:45PM +0300, Vadim V. Zhytnikov wrote:
> Dmitry V. Levin пишет:
> >On Thu, Oct 27, 2005 at 10:50:01PM +0300, Vadim V. Zhytnikov wrote:
> >[...]
> >
> >>>Стоит пропатчить gnuplot, чтобы он использовал %_libexecdir.
> >>
> >>Так он его как-раз его и использует.  Он кладёт исполняемый ELF
> >>gnuplot_x11 в libexec.  Поскольку у нас %_libexecdir на
> >>x86_64 устеновлен /usr/lib, то получаем
> >>
> >>/usr/lib/gnuplot/gnuplot_x11
> >>
> >>а должно быть
> >>
> >>/usr/lib64/gnuplot/gnuplot_x11
> >
> >А почему должно быть /usr/lib64/gnuplot/gnuplot_x11 а не
> >/usr/lib/gnuplot/gnuplot_x11 или /usr/libexec/gnuplot/gnuplot_x11?
> 
> Так ведь в нашем biarch x86_64 в /usr/lib должны
> лежать 32-битные файлы а 64-битные в /usr/lib64.
> Или я неверно понимаю взаимоотношение /usr/lib
> и /usr/lib64 ?

А зачем нужен biarch для исполняемых приложений?


-- 
ldv

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

Re: [devel] libexec and x86_64

[Vadim V. Zhytnikov]

Dmitry V. Levin пишет:
> On Thu, Oct 27, 2005 at 12:38:18PM +0300, Vadim V. Zhytnikov wrote:
> 
>>Не секрет, что некоторые пакеты упорно
>>пытаются ставить бинарники в /usr/libexec.
>>Для ix86 мы их перенаправляем в /usr/lib
>>установкой %_libexecdir=/usr/lib и здесь
>>всё ОК.  Но для x86_64 в macros видим
>>
>>%_libexecdir		/usr/lib
>>%_libdir		/usr/lib64
>>
>>Не бага ли это?
> 
> 
> Скорее всего, нет.
> 
> 
>>Мне кажется, что должно быть
>>
>>%_libexecdir		/usr/lib64
> 
> 
> Если бы не проблемы переезда, то я бы давно уже вернул %_libexecdir в
> /usr/libexec.
> 
> 
>>Да, FHS libexec не определяет и не трактует, но,
>>насколько я понимаю, эта директория всё-таки
>>предназначена для arch-зависимых данных.
> 
> 
> Да, конечно.
> Насколько я понимаю, каталог libexec предназначен для arch-зависимых
> исполняемых файлов, в отличие от lib, предназначенного для arch-зависимых
> неисполняемых файлов.  executables vs libraries.
> 
> 
>>Хочу gnuplot для для x86_64, а он ставит
>>gnuplot_x11 в libexec :-(
>>Что патчить - gnuplot или rpm?
> 
> 
> Стоит пропатчить gnuplot, чтобы он использовал %_libexecdir.
> 

Так он его как-раз его и использует.  Он кладёт исполняемый ELF
gnuplot_x11 в libexec.  Поскольку у нас %_libexecdir на
x86_64 устеновлен /usr/lib, то получаем

/usr/lib/gnuplot/gnuplot_x11

а должно быть

/usr/lib64/gnuplot/gnuplot_x11

Разумеется, это легко исправить для gnuplot, но я
засомневался - не следует-ли поправить %_libexecdir

-- 
      Vadim V. Zhytnikov

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

Re: [devel] libexec and x86_64

[Vadim V. Zhytnikov]

Dmitry V. Levin пишет:
> On Thu, Oct 27, 2005 at 10:50:01PM +0300, Vadim V. Zhytnikov wrote:
> [...]
> 
>>>Стоит пропатчить gnuplot, чтобы он использовал %_libexecdir.
>>
>>Так он его как-раз его и использует.  Он кладёт исполняемый ELF
>>gnuplot_x11 в libexec.  Поскольку у нас %_libexecdir на
>>x86_64 устеновлен /usr/lib, то получаем
>>
>>/usr/lib/gnuplot/gnuplot_x11
>>
>>а должно быть
>>
>>/usr/lib64/gnuplot/gnuplot_x11
> 
> 
> А почему должно быть /usr/lib64/gnuplot/gnuplot_x11 а не
> /usr/lib/gnuplot/gnuplot_x11 или /usr/libexec/gnuplot/gnuplot_x11?
> 
> 

Так ведь в нашем biarch x86_64 в /usr/lib должны
лежать 32-битные файлы а 64-битные в /usr/lib64.
Или я неверно понимаю взаимоотношение /usr/lib
и /usr/lib64 ?

Кстати говоря, сборка из SuSE использует именно
/usr/lib64/gnuplot/gnuplot_x11



-- 
      Vadim V. Zhytnikov

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

Re: [devel] libexec and x86_64

[Vadim V. Zhytnikov]

Dmitry V. Levin пишет:

>>Так ведь в нашем biarch x86_64 в /usr/lib должны
>>лежать 32-битные файлы а 64-битные в /usr/lib64.
>>Или я неверно понимаю взаимоотношение /usr/lib
>>и /usr/lib64 ?
> 
> 
> А зачем нужен biarch для исполняемых приложений?
> 

Да, понял - /usr/lib /usr/lib64 это для biarch библиотек.
И gnuplot прав - gnuplot_x11 самое место в libexec.
Из-за нашего старинного дефолтного
маппинга libdir=libexecdir=/usr/lib в голове
образовалась каша.  И равным образом каша
из библиотек и исполнимых файлов в /usr/lib

-- 
      Vadim V. Zhytnikov

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

[devel] Re: libexec and x86_64

[Anton Farygin]

On Fri, 28 Oct 2005 00:51:05 +0300, Vadim V. Zhytnikov wrote:

> Dmitry V. Levin пишет:
> 
>>>Так ведь в нашем biarch x86_64 в /usr/lib должны
>>>лежать 32-битные файлы а 64-битные в
>>>/usr/lib64. Или я неверно понимаю
>>>взаимоотношение /usr/lib и /usr/lib64 ?
>> 
>> 
>> А зачем нужен biarch для исполняемых
>> приложений?
>> 
>> 
> Да, понял - /usr/lib /usr/lib64 это для biarch
> библиотек. И gnuplot прав - gnuplot_x11 самое
> место в libexec. Из-за нашего старинного
> дефолтного маппинга libdir=libexecdir=/usr/lib в
> голове образовалась каша.  И равным
> образом каша из библиотек и исполнимых
> файлов в /usr/lib

Кстати, а почему мы не используем libexec ?
Или этот вопрос уже задавался ?

Rgds,
Rider

Re: [devel] Re: libexec and x86_64

[Anton D. Kachalov]

On Fri, Oct 28, 2005 at 11:59:20AM +0400, Anton Farygin wrote:
> Кстати, а почему мы не используем libexec ?
> Или этот вопрос уже задавался ?
Мы готовы на пару недель разломать Сизиф для переезда из /usr/lib ->
/usr/libexec? :)
Вопрос ровно в этом.

--
mouse

Re: [devel] Re: libexec and x86_64

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

On Fri, Oct 28, 2005 at 07:14:44PM +0400, Anton D. Kachalov wrote:

>> Кстати, а почему мы не используем libexec ?
>> Или этот вопрос уже задавался ?
ADK> Мы готовы на пару недель разломать Сизиф для переезда из /usr/lib ->
ADK> /usr/libexec? :)
ADK> Вопрос ровно в этом.

IMHO да. branch уже всё равно форкнут давно :) Только предупредить за
сутки надо в sisyphus. Идея:

1. в daedalus кладётся обновлённый rpm, где макрос libexec указывает куда
надо.
2. в sisyphus/devel публикуется об этом анонс (чтобы мантейнеры, кто
может, протестировали бы сборку в hasher своих пакетов с новым rpm, да ещё
и работоспособность их проверили)
3. через несколько дней можно вливать этот rpm в sisyphus.

Кстати о пересборке. У нас не делается теста на новые/удалённые файлы в
бинарных пакетах после автоматической пересборки? Если мантейнер
использует wildcards для имён файлов в %files, то пакет может
пересобираться, но не содержать некоторых бинарников, которые должен
содержать.

У меня asterisk такой -- в зависимости от окружения собирает разные
модули. Я-то борюсь тем, что указываю все модули поимённо, но, как я
заметил, многие поступают не так.

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

http://freesource.info

Re: [devel] Re: libexec and x86_64

[Alexey Rusakov]

Денис Смирнов wrote:

>ADK> Мы готовы на пару недель разломать Сизиф для переезда из /usr/lib ->
>ADK> /usr/libexec? :)
>ADK> Вопрос ровно в этом.
>
>IMHO да. branch уже всё равно форкнут давно :) Только предупредить за
>сутки надо в sisyphus. Идея:
>
>1. в daedalus кладётся обновлённый rpm, где макрос libexec указывает куда
>надо.
>2. в sisyphus/devel публикуется об этом анонс (чтобы мантейнеры, кто
>может, протестировали бы сборку в hasher своих пакетов с новым rpm, да ещё
>и работоспособность их проверили)
>3. через несколько дней можно вливать этот rpm в sisyphus.
>  
>
Поддерживаю.

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Re: libexec and x86_64

[Dmitry V. Levin]

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

On Sat, Oct 29, 2005 at 06:48:41PM +0400, Денис Смирнов wrote:
> On Fri, Oct 28, 2005 at 07:14:44PM +0400, Anton D. Kachalov wrote:
> 
> >> Кстати, а почему мы не используем libexec ?
> >> Или этот вопрос уже задавался ?
> ADK> Мы готовы на пару недель разломать Сизиф для переезда из /usr/lib ->
> ADK> /usr/libexec? :)
> ADK> Вопрос ровно в этом.
> 
> IMHO да. branch уже всё равно форкнут давно :) Только предупредить за
> сутки надо в sisyphus. Идея:
> 
> 1. в daedalus кладётся обновлённый rpm, где макрос libexec указывает куда
> надо.
> 2. в sisyphus/devel публикуется об этом анонс (чтобы мантейнеры, кто
> может, протестировали бы сборку в hasher своих пакетов с новым rpm, да ещё
> и работоспособность их проверили)
> 3. через несколько дней можно вливать этот rpm в sisyphus.
> 
> Кстати о пересборке. У нас не делается теста на новые/удалённые файлы в
> бинарных пакетах после автоматической пересборки? Если мантейнер
> использует wildcards для имён файлов в %files, то пакет может
> пересобираться, но не содержать некоторых бинарников, которые должен
> содержать.
> 
> У меня asterisk такой -- в зависимости от окружения собирает разные
> модули. Я-то борюсь тем, что указываю все модули поимённо, но, как я
> заметил, многие поступают не так.

А какая нам от этого будет польза, помимо получения удовольствия от
процесса (if any)?


-- 
ldv

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

Re: [devel] Re: libexec and x86_64

[Volkov Serge]

Dmitry V. Levin пишет:

>On Sat, Oct 29, 2005 at 06:48:41PM +0400, Денис Смирнов wrote:
>  
>
>>On Fri, Oct 28, 2005 at 07:14:44PM +0400, Anton D. Kachalov wrote:
>>
>>    
>>
>>>>Кстати, а почему мы не используем libexec ?
>>>>Или этот вопрос уже задавался ?
>>>>        
>>>>
>>ADK> Мы готовы на пару недель разломать Сизиф для переезда из /usr/lib ->
>>ADK> /usr/libexec? :)
>>ADK> Вопрос ровно в этом.
>>
>>IMHO да. branch уже всё равно форкнут давно :) Только предупредить за
>>сутки надо в sisyphus. Идея:
>>
>>1. в daedalus кладётся обновлённый rpm, где макрос libexec указывает куда
>>надо.
>>2. в sisyphus/devel публикуется об этом анонс (чтобы мантейнеры, кто
>>может, протестировали бы сборку в hasher своих пакетов с новым rpm, да ещё
>>и работоспособность их проверили)
>>3. через несколько дней можно вливать этот rpm в sisyphus.
>>
>>Кстати о пересборке. У нас не делается теста на новые/удалённые файлы в
>>бинарных пакетах после автоматической пересборки? Если мантейнер
>>использует wildcards для имён файлов в %files, то пакет может
>>пересобираться, но не содержать некоторых бинарников, которые должен
>>содержать.
>>
>>У меня asterisk такой -- в зависимости от окружения собирает разные
>>модули. Я-то борюсь тем, что указываю все модули поимённо, но, как я
>>заметил, многие поступают не так.
>>    
>>
>
>А какая нам от этого будет польза, помимо получения удовольствия от
>процесса (if any)?
>  
>
Здесь вопрос не в присутствии (if any), а в целостности вновь 
испекаемого пакета.
Приследуются цель того, чтобы при установке в рабочую систему ваша 
система продолжала работать стабильно! Теоретически проверить 
целостность достаточно просто:
1) если пакет существует в репозитории, то простая выборка по файлам из 
старого пакета и сравнение со списком из вновь испеченого должна дать 
полное совпадение, за исключением библиотек, плагинов и вообще всех 
файлов, которые имеют версионность в названии
2) если пакет новый, то его совершенно логично добавляем без проверки
3) для исключений из п.1 можно использовать вариант сравнения названия 
файла, т.е. статической его части, которую должен будет определить 
мейнтейнер пакета определяя какую-нибудь переменную

и данный функционал наверное имеет смысл выполнить в виде некого плагина 
к sisyphus_check

Re: [devel] Re: libexec and x86_64

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

On Sun, Oct 30, 2005 at 10:51:26PM +0300, Dmitry V. Levin wrote:

>> У меня asterisk такой -- в зависимости от окружения собирает разные
>> модули. Я-то борюсь тем, что указываю все модули поимённо, но, как я
>> заметил, многие поступают не так.
DVL> А какая нам от этого будет польза, помимо получения удовольствия от
DVL> процесса (if any)?

Думается ровно такая же, какой является разделение /usr/bin и /usr/lib.
Разделение мух и котлет.

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

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

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

http://freesource.info
----------------------------------------------------------------------------
> блин... на 19" в текст-моде... это хардкор...
а представьте, мне на 21" каково? ;-)
		-- mike in community@

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 --]