Pengaruh kompilasi dari sumber pada aplikasi yang sudah diinstal


8

Saya menggunakan Ubuntu 12.04. Katakanlah saya telah menginstal package xdari repositori (dengan semua dependensinya) di versi 1.7 tetapi saya memerlukan beberapa fungsionalitas yang hanya tersedia di versi 1.8, jadi saya mengunduh source tar dan mengompilasinya:

./configure  
make  
make install
  • Apakah ini menimpa 1,7 binari yang ada?
  • Jika binari yang ada ditimpa, apakah manajer paket mencerminkan versi baru (1.8) dan dapat package xdiperbarui oleh manajer paket di masa depan?
  • Jika package ymemiliki ketergantungan package x 1.8- apakah akan dipenuhi?

Saya telah berusaha mencari sumber daring yang menjelaskan hal ini. Jika Anda memiliki rekomendasi, harap beri tahu saya.


Jika Anda sengaja menghindari manajer paket, apa yang di bumi membuat Anda berpikir itu selanjutnya akan mengenali apa yang Anda diinstal?
Shadur

@ Shadur Aspek pertanyaan ini pada dasarnya bermuara pada masalah apa yang terjadi, tepatnya ketika Anda menginstal perangkat lunak dari sumber menggunakan make install. Saya pikir itu jelas dari jawaban bahwa pada dasarnya semua yang terjadi adalah bahwa file disalin ke direktori di dalam awalan instalasi (meskipun ternyata ini adalah dengan kemungkinan bahwa beberapa file konfigurasi dapat dimasukkan ke dalam /etcdan beberapa data yang secara dinamis dapat diubah mewakili awal. keadaan sesuatu dapat dimasukkan ke dalam /var). Namun, jika Anda merasa itu tidak jelas, saya akan senang mengedit jawaban saya untuk menjelaskan.
Eliah Kagan

@EliahKagan saya kebanyakan hanya retorika untuk Philip, di sana.
Shadur

Jawaban:


12

Sebagian besar .debpaket, apakah disediakan oleh repositori resmi, dipasang dengan awalan /usr.

Artinya adalah bahwa executable yang dimaksudkan untuk dijalankan oleh pengguna masuk /usr/binatau /usr/sbin(atau /usr/gamesjika itu adalah permainan), pustaka bersama masuk /usr/lib, data bersama platform-independen masuk /usr/share, file header masuk /usr/include, dan kode sumber yang dipasang secara otomatis masuk /usr/src.

Sebagian kecil dari paket digunakan /sebagai awalan. Sebagai contoh, bashpaket menempatkan bashexecutable /bin, bukan /usr/bin. Ini adalah untuk paket-paket yang menyediakan esensi telanjang untuk dijalankan dalam mode pengguna tunggal (seperti mode pemulihan) dan untuk memulai mode multi-pengguna (tapi ingat, yang sering menyertakan fungsionalitas untuk me-mount beberapa jenis jaringan yang dibagikan ... kalau /usr- kalau ada sistem file jarak jauh).

Sebagian kecil dari .debpaket, kebanyakan dibuat dengan Quickly , membuat folder khusus paket di dalam /optdan meletakkan semua file mereka di sana. Selain itu, sebagian besar waktu /optadalah lokasi yang digunakan oleh perangkat lunak yang diinstal dari installer yang dapat dieksekusi yang tidak menggunakan manajer paket sistem tetapi tidak melibatkan kompilasi dari sumber. (Misalnya, jika Anda menginstal program berpemilik seperti MATLAB, kemungkinan Anda akan memasukkannya /opt.)

Berbeda dengan semua ini, ketika Anda mengunduh arsip sumber (atau mendapatkan kode sumber dari sistem kontrol revisi seperti Bazaar atau git), membangunnya, dan memasangnya, biasanya memasang ke awalan /usr/local(kecuali jika Anda menyuruhnya melakukan jika tidak). Ini berarti executable Anda pergi /usr/local/bin, /usr/local/libatau /usr/local/games, perpustakaan Anda di /usr/local/lib, dan sebagainya.

Ada beberapa pengecualian untuk ini - beberapa program, secara default, menginstal ke /usrawalan dan dengan demikian akan menimpa instalasi dari program yang sama dari .debpaket. Biasanya Anda dapat mencegah ini dengan menjalankan ./configure --prefix=/usr/localalih-alih ./configuresaat Anda membangunnya. Saya kembali menekankan bahwa biasanya ini tidak perlu.

(Karena alasan inilah masuk akal bagi Anda untuk memasukkan kode sumber yang sedang Anda bangun dan akan dipasang untuk penggunaan di seluruh sistem /usr/local/src, yang ada untuk tujuan itu.)

Dengan asumsi versi paket sudah diinstal /usrdan versi yang Anda instal dari sumber ada di /usr/local:

  • File dari paket yang diinstal tidak akan ditimpa.

    Biasanya versi yang lebih baru akan berjalan ketika Anda menjalankan program secara manual dari command-line (dengan asumsi /usr/local/binatau di mana pun executable diinstal berada dalam PATHvariabel lingkungan Anda dan muncul sebelum /usrdirektori -prefixed yang sesuai , seperti /usr/bin).

    Tetapi mungkin ada beberapa masalah dengan peluncur apa yang dibuat dan dapat diakses melalui menu atau pencarian. Selain itu, jika Anda telah menginstal lebih dari satu versi perpustakaan di tempat yang berbeda, itu bisa menjadi sedikit lebih rumit untuk menentukan mana yang akan digunakan oleh perangkat lunak apa.

    Jika Anda tidak benar - benar menggunakan kedua versi program atau pustaka, maka seringkali Anda harus menghapus versi yang tidak Anda gunakan, meskipun dalam situasi terbatas Anda mungkin ingin tetap menginstal paket untuk memenuhi dependensi.

Namun, jika karena alasan apa pun file ditimpa (misalnya, jika kode sumber dipasang /usrbukan /usr/local):

  • Manajer paket tidak akan tahu apa pun tentang bagaimana perangkat lunak yang diinstalnya diubah. Itu akan berpikir versi lama diinstal. Masalah buruk dapat terjadi. Anda harus menghindari ini. Jika Anda telah membuat situasi ini, Anda harus menghapus instalasi perangkat lunak yang Anda instal dari sumber (biasanya dengan sudo make uninstalldi direktori), dan kemudian menghapus paket atau paket yang menyediakan file yang ditimpa (karena mereka tidak akan dikembalikan dengan menghapus instalasi versi yang diinstal dari sumber). Kemudian instal ulang versi apa pun yang Anda inginkan./usr/local/src/program-or-library-name

Adapun memenuhi dependensi:

  • Jika ada .debpaket yang tergantung pada perangkat lunak yang Anda instal dari sumber, dan membutuhkan versi yang Anda instal dari sumber (atau lebih tinggi), paket itu tidak akan berhasil diinstal. (Atau, lebih tepatnya, Anda mungkin dapat "menginstal" tetapi itu tidak akan pernah "dikonfigurasi" sehingga Anda tidak akan dapat menggunakannya.) Ketergantungan diselesaikan dengan versi paket apa yang diinstal, bukan oleh perangkat lunak apa yang sebenarnya Anda miliki.

    Demikian pula, perangkat lunak setidaknya akan mencoba untuk menginstal sepenuhnya bahkan jika Anda telah secara manual menghapus file yang disediakan oleh paket-paket tempat perangkat lunak yang diinstal tergantung. (Anda seharusnya tidak mencoba memanfaatkannya untuk tujuan apa pun. Manajer paket yang beroperasi berdasarkan informasi palsu hampir selalu merupakan hal yang buruk.)

Oleh karena itu, jika Anda tidak dapat menemukan paket yang menyediakan versi perangkat lunak yang Anda butuhkan, Anda mungkin perlu membuat .debpaket Anda sendiri dari perangkat lunak yang Anda kompilasi, dan instal dari paket itu. Kemudian manajer paket akan tahu apa yang sedang terjadi. Membuat paket untuk Anda gunakan sendiri, yang tidak perlu Anda lakukan dengan baik di komputer orang lain, sebenarnya tidak terlalu sulit. (Tapi saya merasa itu mungkin berada di luar ruang lingkup pertanyaan Anda, seperti yang saat ini dinyatakan.)


Terima kasih atas tanggapan terperinci Anda, hal ini membuat banyak konsep menjadi jelas
Philip D'Rozario

5

Apa yang Anda instal dari pusat perangkat lunak atau dengan perintah APT ( apt-get, aptitude) atau dengan dpkgdikenal dengan sistem manajemen paket. dpkgadalah alat manipulasi paket tingkat rendah, APT dan teman-teman adalah alat tingkat tinggi yang meminta dpkguntuk melakukan instalasi aktual dan juga menangani dependensi dan unduhan paket.

Jika Anda mengkompilasi program dari sumber, itu tidak akan diketahui oleh manajer paket. Konvensi di Linux, yang harus Anda ikuti pada kesulitan memiliki kesulitan melacak hal-hal dan instalasi Anda ditimpa, adalah:

  • /bin, /lib, /sbin, /usrDicadangkan untuk manajer paket;
  • kecuali itu /usr/localuntuk administrator sistem - hormati hierarki direktori di sana, tetapi Anda sendiri yang mengelola file.

Lihat Cara terbaik untuk memutakhirkan vim / gvim ke 7.3 di Ubuntu 10.04? untuk daftar cara untuk mendapatkan versi perangkat lunak yang lebih baru. Cara termudah adalah mendapatkan PPA , jika ada. Jika Anda mendapatkan paket biner atau kompilasi dari sumber, saya sarankan menggunakan stow untuk mengelola perangkat lunak yang Anda instal secara manual. Atau, buat .debpaket Anda sendiri - ini lebih berfungsi, tetapi terbayar jika Anda sering memutakhirkan (biasanya mengulang paket untuk versi minor berikutnya sangat cepat) atau jika Anda menggunakan banyak mesin yang menjalankan distribusi yang sama.

Dengan sebagian besar program, jika Anda menjalankan ./configure && make && sudo make install, program diinstal di bawah /usr/local. Periksa dokumentasi yang disediakan dengan sumber (biasanya dalam file bernama READMEatau INSTALL) atau jalankan ./configure --helpuntuk memeriksa apakah ini masalahnya. Jika program diinstal di bawah /usr/local, itu tidak akan mengganggu versi yang disediakan oleh manajer paket. /usr/local/binlebih dulu di sistem PATH. Perhatikan bahwa Anda harus menjalankan make installsebagai administrator (root); jangan dikompilasi sebagai root. Seperti disebutkan di atas, saya sarankan menggunakan stow daripada menginstal langsung ke /usr/local.


1

Ini tergantung pada paket dan banyak hal lainnya

  1. konvensi penamaan yang digunakan - apakah biner berisi nomor versi dalam nama file
  2. instal lokasi - apakah secara default memilih, tetapi versi paket ada di / usr
  3. banyak lagi kemungkinan

Singkat cerita:
Tidak ada jawaban umum. Ini sangat tergantung paket. Anda harus menggunakan +1 PPA resmi jika mungkin dan bukan mengkompilasi dari sumber.


1
Ini sebenarnya sangat tidak biasa untuk program atau perpustakaan yang dikompilasi dari sumber untuk diinstal /opt. /usr/localadalah awalan standar, dan bahkan /usrmerupakan awalan standar yang lebih umum daripada /opt. /optpaling umum digunakan untuk perangkat lunak yang menginstal di dalam direktori khusus yang dinamai untuk aplikasi tertentu (jadi, misalnya, aplikasi bernama Foo mungkin diinstal dengan semua file di dalamnya /opt/foo).
Eliah Kagan
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.