[ English | 中文 (简体, 中国) | русский | português (Brasil) | नेपाली | 한국어 (대한민국) | Indonesia | français | español | esperanto | English (United Kingdom) | Deutsch ]

Packaging Software

Paket software

Bagian ini menjelaskan beberapa hal umum yang harus diketahui pengembang tentang pengemasan perangkat lunak. Konten ini sebagian besar berasal dari praktik terbaik.

Pengembang yang membuat paket dapat dibandingkan dengan insinyur yang membuat mobil hanya dengan alat manual dan sangat sedikit. Jika insinyur membutuhkan alat khusus untuk membuat mobil, ia juga harus membuat alat itu.

Sebagai pengembang, jika Anda akan menambahkan perpustakaan bernama "foo", paket harus mematuhi standar berikut:

  • Jadilah paket gratis yang dibuat dengan perangkat lunak gratis.

  • Sertakan semua alat yang diperlukan untuk membangun paket.

  • Memiliki hulu yang aktif dan responsif untuk mempertahankan paket.

  • Patuhi Filesystem Hierarchy Standards (FHS). Tidak diperlukan tata letak sistem file tertentu.

Salinan embedded (tertencap) tidak diizinkan

Bayangkan jika semua paket memiliki salinan jQuery lokal. Jika lubang keamanan ditemukan di jQuery, kita harus menulis lebih dari 90 patch di Debian, satu untuk setiap paket yang menyertakan salinan. Ini sama sekali tidak praktis. Oleh karena itu, Horizon tidak dapat diterima untuk menyalin kode dari repositori lain saat membuat paket. Menyalin kode dari repositori lain cenderung membuat fork, menyimpang dari kode hulu. Fork menyertakan kode yang tidak dipelihara, jadi jika bug ditemukan di hulu asli, itu tidak dapat dengan mudah diperbaiki dengan memperbarui satu paket.

Alasan lain untuk menghindari menyalin pustaka ke kode sumber Horizon adalah bahwa hal itu dapat membuat lisensi yang bertentangan. Mendistribusikan sumber dengan lisensi yang bertentangan dalam satu tarball mencabut hak dalam best case. Dalam worst case, Anda dapat dianggap bertanggung jawab secara hukum.

Free software

Distribusi Red Hat, Debian, dan SUSE hanya dibuat dari perangkat lunak gratis (gratis seperti dalam Libre, atau kebebasan berbicara). Perangkat lunak yang kami sertakan dalam repositori kami gratis. Alat-alatnya juga gratis, dan tersedia dalam distribusi.

Karena pengelola paket peduli dengan kualitas paket yang kami unggah, kami menjalankan tes yang tersedia dari repositori hulu. Ini juga memenuhi syarat persyaratan pengujian sebagai persyaratan bangunan. Aturan yang sama berlaku untuk membangun perangkat lunak seperti untuk perangkat lunak itu sendiri. Persyaratan bangunan khusus yang tidak termasuk dalam distribusi keseluruhan tidak diperbolehkan.

Contoh perangkat lunak yang secara historis membatasi, tidak bebas adalah Selenium. Untuk waktu yang lama, Selenium hanya tersedia dari repositori Debian yang tidak bebas. Alasannya adalah hulu termasuk beberapa binari .xpi. File .xpi ini menyertakan beberapa file .dll Windows dan Linux .so. Karena mereka tidak dapat dibangun kembali dari sumbernya, semua python-selenium dinyatakan tidak bebas. Jika kita membuat Horizon build-depend pada python-selenium, ini berarti Horizon tidak akan berada di main Debian lagi (contrib dan non-bebas not dianggap bagian dari Debian). Baru-baru ini, pengelola paket python-selenium memutuskan untuk menghapus file .xpi dari python-selenium, dan mengunggahnya ke Debian Experimental (kali ini, pada intinya, bukan dalam tidak bebas). Jika pada suatu saat Horizon dapat menggunakan python-selenium (tanpa file .xpi yang tidak bebas), maka kita dapat menjalankan tes Selenium pada waktu paket build.

Menjalankan unit test pada waktu build

Lingkungan build di dalam distribusi tidak persis sama dengan yang ada di gerbang OpenStack. Misalnya, versi perpustakaan yang diberikan dapat sedikit berbeda dari yang ada di gerbang. Kami ingin mendeteksi ketika ada perbedaan yang bermasalah sehingga kami dapat memperbaikinya. Kapanpun memungkinkan, cobalah untuk membuat masa pakai pengelola paket lebih mudah, dan biarkan mereka (atau bantu mereka) untuk menjalankan tes unit.

Kebijakan Minified JavaScript

Dalam distribusi perangkat lunak gratis yang secara aktif memelihara paket-paket OpenStack (seperti RDO, Debian, dan Ubuntu), minified JavaScript dianggap tidak bebas. Ini berarti bahwa JavaScript yang diperkecil seharusnya not ada di kode sumber hulu. Paling tidak, versi non-minify harus ada di sebelah versi minified. Juga, perhatikan potensi masalah keamanan dengan minifiers. blog post ini menjelaskan dengan sangat baik.

Versi komponen

Berhati-hatilah dengan versi semua komponen yang Anda gunakan dalam aplikasi Anda. Karena tidak dapat menanamkan komponen tertentu dalam Horizon, kita harus menggunakan apa yang ada dalam distribusi, termasuk semua font, JavaScript, dll. Di sinilah agak rumit.

Dalam sebagian besar distribusi, tidak dapat diterima untuk memiliki beberapa versi dari perangkat lunak yang sama. Dalam sistem Red Hat, secara teknis dimungkinkan untuk menginstal 2 versi dari satu perpustakaan pada saat yang sama, tetapi beberapa pembatasan berlaku, terutama untuk penggunaan. Namun, pengelola paket berusaha menghindari beberapa versi sebanyak mungkin. Untuk resolusi ketergantungan paket, mungkin perlu menyediakan paket untuk paket yang tergantung juga. Misalnya, jika Anda memiliki Django-1.4 dan Django-1.8 dalam rilis yang sama, Anda harus menyediakan Horizon built untuk Django-1.4 dan paket lain yang menyediakan Horizon built untuk Django-1.8. Ini adalah upaya besar dan perlu dievaluasi dengan cermat.

Di Debian, umumnya dilarang memiliki beberapa versi dari perpustakaan yang sama dalam rilis Debian yang sama. Sangat sedikit pengecualian yang ada.

Versi komponen memiliki konsekuensi bagi penulis hulu yang bersedia mengintegrasikan perangkat lunak mereka dalam distribusi hilir. Situasi terbaik adalah ketika dimungkinkan untuk mendukung versi apa pun yang saat ini tersedia di distribusi target, hingga versi terbaru di hulu. Mendeklarasikan batas bawah dan atas dalam requirement.txt Anda tidak menyelesaikan masalah. Itu memungkinkan semua tes untuk lulus di gate karena mereka dijalankan terhadap satu set sempit versi di requirement.txt. Distribusi hilir mungkin masih memiliki beberapa dependensi dengan versi di luar rentang yang ditentukan dalam requirement.txt. Ketergantungan ini dapat menyebabkan kegagalan yang tidak tertangkap di gate OpenStack.

Terkadang tidak mungkin untuk mendukung semua versi perpustakaan. Mungkin terlalu banyak pekerjaan, atau mungkin sangat sulit untuk menguji di gate. Dalam hal ini, yang terbaik adalah menggunakan apa pun yang tersedia di dalam distribusi target. Misalnya, Horizon saat ini mendukung jQuery> = 1.7.2, karena inilah yang saat ini tersedia di Debian Jessie dan Ubuntu Trusty (LTS terakhir).

Anda dapat mencari dalam distribusi perangkat lunak foo menggunakan perintah seperti dnf search foo, atau zypper se -s foo. `` dnf info foo`` mengembalikan informasi lebih rinci tentang paket tersebut.

Filesystem Hierarchy Standards

Setiap distribusi harus mematuhi Standar Hierarki Filesystem (FHS). FHS mendefinisikan seperangkat aturan yang kita must ikuti sebagai pengelola paket. Beberapa yang paling penting adalah:

  • /usr dianggap hanya baca. Perangkat lunak tidak boleh menulis di /usr saat runtime. Namun, tidak masalah untuk menulis paket pasca instalasi untuk menulis di /usr. Ketika aturan ini tidak diikuti, distribusi harus menulis banyak trik untuk meyakinkan Horizon untuk menulis hanya dalam /var/lib. Sebagai contoh, distribusi menulis symlinks ke /var/lib/openstack-dashboard, atau patched local_settings.py default untuk menulis SECRET_KEY di /var.

  • Konfigurasi harus selalu di /etc, tidak peduli apa. Ketika aturan ini tidak diikuti, pengelola paket harus menempatkan symlink ke /etc/openstack-dashboard/local_settings dalam distribusi berbasis Red Hat daripada menggunakan secara langsung /usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py yang Horizon harapkan. Di Debian, file konfigurasi bernama /etc/openstack-dashboard/local_settings.py.

Packaging Horizon

Mengapa kami menggunakan XStatic

XStatic menyediakan fitur berikut yang saat ini tidak tersedia secara default dengan sistem seperti NPM dan Grunt:

  • Pemeriksaan dependensi: Pemeriksaan XStatic bahwa dependensi, seperti font dan lib JavaScript, tersedia di distribusi downstream.

  • Komponen yang dapat digunakan kembali di seluruh proyek: Sistem XStatic memastikan komponen dapat digunakan kembali oleh paket lain, seperti Fuel.

  • Registri system-wide (seluruh sistem) dari konten statis: XStatic membawa registri komponen di seluruh sistem, sehingga mudah untuk memeriksa apakah ada yang hilang. Misalnya, ia dapat mendeteksi jika tidak ada egg-info, atau ada ketergantungan paket rusak.

  • Tidak ada konten yang embedded: Sistem XStatic membantu kami menghindari menyematkan (embedding) file yang sudah tersedia dalam distribusi, misalnya, paket libjs-* or fonts-. Bahkan menyediakan lapisan kompatibilitas untuk distribusi. Tidak setiap distribusi menempatkan file statis di posisi yang sama di sistem file. Jika Anda mengemas paket XStatic untuk distribusi Anda, pastikan Anda menggunakan file statis yang disediakan oleh distribusi tertentu. Setelah mengumpulkan, paket XStatic menjadi *no guarantee untuk mendapatkannya menjadi distribusi. XStatic hanya menyediakan lapisan abstraksi untuk menggunakan distribusi file statis yang disediakan.

  • Sistem paket build terputus dari jaringan luar (karena beberapa alasan). Sistem pengemasan lainnya mengunduh dependensi langsung dari internet tanpa memverifikasi bahwa file yang diunduh utuh, cocok dengan checksum yang disediakan, dll. Dengan sistem lain ini, tidak ada cara untuk menyediakan mirror, proxy, atau cache, membuat build menjadi lebih tidak stabil ketika masalah jaringan kecil ditemui.

Fitur sebelumnya adalah persyaratan penting sistem pengemasan Horizon. Setiap sistem baru must menyimpan fitur-fitur ini. Meskipun XStatic dapat berarti beberapa langkah tambahan dari masing-masing pengembang, langkah-langkah tersebut membantu menjaga konsistensi dan mencegah kesalahan di seluruh proyek.

Pengemasan Horizon untuk distribusi

Horizon adalah modul Python. Lebih disukai, itu dipasang di lokasi default untuk python. Di Fedora dan openSUSE, ini adalah /usr/lib/python3.7/site-packages/horizon, dan di Debian/Ubuntu it is /usr/lib/python3.7/dist-packages/horizon.

File konfigurasi harus berada di bawah /etc/openstack-dashboard. File kebijakan harus dibuat dan dimodifikasi di sana juga.

Diharapkan manage.py collectstatic akan dijalankan selama pembuatan paket. Ini adalah recommended way untuk aplikasi Django. Bergantung pada konfigurasi, mungkin diperlukan manage.py compress selama pembuatan paket juga.