Чем отличается установка из RPM от компиляции

> когда я попытался установить оставшуюся часть используя rpm

Что компилилось и что за оставшаяся часть? Если просто configure без параметров делать, то, как правило, проги ставятся в /usr/local, а то, что идёт в RPM ставится в /usr. Возможно, /usr/local/lib не прописан в /etc/ld.so.conf, возможно после make install надо сделать ldconfig, возможно в PATH чего не хватает или то, что в RPM ищет что-то жёстко в /usr, мало ли.

> А в разнобой что нельзя ?

Можно, надо только знать кому чего и где надо. И компилировать так, чтобы то, что надо лежало где надо.

В общем, если с development'ом туго, лучше не лезь в компиляцию.

RPM файл содержит набор файлов, которые в целом составляют пакет. При установке rpm-ок происходит тупое разархивирование. rpm-пакет никак не искусственный интеллект.

Насчёт того почему исходники и rpm устанавливал совместно. Объясню. У меня инетернет через сотовый телефон подключеный через bluetuth а для него нет драйвера для Linux. Приходится перегружать в Windows По ошибке я скачал один модуль в rpm а перегружаться опять в win только ради этого модуля было сразу лень. Кто куда что пишет в /usr/local или /usr я не знал. За это спасибо. Это я уверен и была причина ошибки;

По поводу того что с девелопментом туго Есть люди которые родились и сразу всё знают (вы наверно один из них). Мне вот не повезло. Поэтому приходится задавать вопросы.

<У меня инетернет через сотовый телефон подключеный через bluetuth а для него нет драйвера для Linux.

А ты уверен? Может и есть. В ядре упоминается bluetooth.

Linux Bluetooth subsystem consist of several layers: │
│ Bluetooth Core (HCI device and connection manager, scheduler) │
│ HCI Device drivers (interface to the hardware) │
│ L2CAP Module (L2CAP protocol) │
│ SCO Module (SCO links) │
│ RFCOMM Module (RFCOMM protocol) │
│ BNEP Module (BNEP protocol) │
│ CMTP Module (CMTP protocol)
-------------------------------------
To use Linux Bluetooth subsystem, you will need several user-space │
│ utilities like hciconfig and hcid. These utilities and updates to │
│ Bluetooth kernel modules are provided in the BlueZ packages. │
│ For more information, see <http://bluez.sourceforge.net/>;.
-----------------------------------------
INTRODUCTION

The USB Bluetooth driver supports any USB Bluetooth device.
It currently works well with the Linux USB Bluetooth stack from Axis
(available at http://developer.axis.com/software/bluetooth/ ) and
has been rumored to work with other Linux USB Bluetooth stacks.


CONFIGURATION

Currently the driver can handle up to 256 different USB Bluetooth
devices at once.

If you are not using devfs:
The major number that the driver uses is 216 so to use the driver,
create the following nodes:
mknod /dev/ttyUB0 c 216 0
mknod /dev/ttyUB1 c 216 1
mknod /dev/ttyUB2 c 216 2
mknod /dev/ttyUB3 c 216 3
.
.
.
mknod /dev/ttyUB254 c 216 254
mknod /dev/ttyUB255 c 216 255

If you are using devfs:
The devices supported by this driver will show up as
/dev/usb/ttub/{0,1,...}

When the device is connected and recognized by the driver, the driver
will print to the system log, which node the device has been bound to.


CONTACT:

If anyone has any problems using this driver, please contact me, or
join the Linux-USB mailing list (information on joining the mailing
list, as well as a link to its searchable archive is at
http://www.linux-usb.org/ )


Greg Kroah-Hartman
greg@kroah.com

ВОТ только бы ещё перевести =)

Интиресно. Я попробую поковыряться. Меня смущает то что как таковой device - bluetooth был найден автоматически. Но вот как произвести спаривание компютера и телефона. А после этого найти в телефоне модем... Хммм. Вообще попробую сегодня или завтра. Спасибо за информацию

> У меня инетернет через сотовый телефон подключеный через bluetuth а для него нет драйвера для Linux

Слабо улавливаю связь между DVD-проигрывателями и Bluetooth.

> Это я уверен и была причина ошибки

Ну, это далеко не факт. Я привёл только самые-самые, кроме них есть ещё куча других возможных причин.

> Мне вот не повезло. Поэтому приходится задавать вопросы.

Вопросы можно задавать разные. Что ответить школьнику (или мне :) ), который спросит: "Я вот тут в гараже самолёт построил по чертежам, а он не летает. В чём может быть дело?". Я не аваконструктор, так я и не лезу в проектирование и даже сборку самолётов, потому как не рублю в этом ни хрена. Если, вдруг, интерес заест, то я сначала изучу этот вопрос, хотя бы в минимально необходимом объёме.

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

1. Установка из RPM.

Происходит тупое разжатие бинарных файлов и распихивание их по нужным каталогам. Производится занесение факта установки пакета в специальную базу данных (вот почему у вас не были видны "самособранные" программы -- чуть ниже). RPM -- тупой, если что-то не занесено в его базу, он считает, что данный софт не установлен. И ld.so.conf и ldconfig тут ни при чём.

2. Установка из исходников.

Происходит подстройка некоторых параметров софта под конкретную конфигурацию системы, сборка софта и его установка. В случае make install никакой информации о том, что данный софт установлен, никуда не пишется -- rpm не увидит этих программ.

Для того, чтобы RPM увидел "самособранный" пакет, есть аж три пути:

а) Качать src.rpm и собирать.

б) Скачать программу checkinstall, тщательно прочитать две страницы документации, собрать, настроить. В дальнейшем вместо make install говорить просто checkinstall.

в) Самому написать .spec-файл к скачанным исходникам и сделать rpm-пакет, после чего установить его при помощи rpm.

Можно долго говорить на тему, а как же правильно -- качать собранные дядей Васей бинарные пакеты или собирать самому. Я не хочу разводить на эту тему флейм, но скажу так. Хватает знаний (!), квалификации (!), времени и желания "вылизать" систему -- собирайте из сырцов. Нужно "просто установил, поправил конфиг и заработало, пусть и неоптимально" -- пользуйтесь готовыми бинарными пакетами.

Я уж не знаю у кого какой опыт но основываясь на моём впечатлении - в Linux есть 4 типа инсталяции 1. Самый бестолковый - устанавливать RPM. Почему бестолковый ? потому что если не дай Бог что то в системе не так - то получить информацию о ошибке тяжело или вообще невозможно. 2. Классический. Сборка из исходников. Может кому то кажется что сделать это сложно но в принципе для большинства пакетов которые мне приходилось собирать три команды configure , make , make install прекрасно работали. В отличии от сборки из rpm тут присутствует хоть какая то проверка системы на совместимость и в ошибках более или менее чётко видно почему пакет не может быть установлен 3. Установка в виде запуска бинарного файла (как в Windows) Я не много видел пакетов которые устанавливаются таким образом. Но это самый мне кажется user friendly вариант. Потому что от вас скрываются все ненужные для вас технические детали. Уж не знаю почему но этот вариант не очень популярен. Наверно потому что никто ещё не написал Open Source Install Shield 4. Java based install - штука хорошая, красивая но для маленьких пакетов слишком дорогая (увеличивается объём пакета, надо поставлять пакет вместе с JVM). Хотя скажу чесно если бы я делал пакет для установки - именно такой бы путь я и выбрал.

Вообщем из всего вышесказаного могу сказать что сборка из исходников это вполне разумное сочетание сложности установки и получаемого результата; Так что я наверно буду собирать их исходников как и собирал раньше; Поправте меня если я не прав, но мне кажется такой подход вполне соответствует идеологии Linux.

> 1. Самый бестолковый - устанавливать RPM.

Не знаю, как RPM, но apt-get+dpkg+команда Debian работают отлично - битых dependencies ещё не видел, хотя ветераны говорят, что в sid бывают. По простоте установки софта аналогов ещё не видел - установка в одну строчку вместе с закачкой из Нета.

> 2. Классический. Сборка из исходников. ...три команды configure , make , make install прекрасно работали.

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

> 3. Установка в виде запуска бинарного файла

Большой геморрой и нафик не надо - зачем дублировать код по проверке зависимостей в каждом пакете, если достаточно его один раз написать в менеджере пакетов.

> 4. Java based install - штука хорошая, красивая но для маленьких пакетов слишком дорогая

Для пакетов под GNU GPL тоже.

> мне кажется такой подход вполне соответствует идеологии Linux.

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