Standar nama dan versi paket Kuliax
stwn
sepertinya kita perlu melakukan standar nama dan versi terhadap paket-
paket yang dibangun dan yang di-backport oleh Kuliax
tujuannya untuk membedakan paket Kuliax dan menghindari *konflik*
dengan paket resmi Debian
usulan nama paket deb (hasil akhir build) ada dua yang terlintas di
kepala:
- aplikasi: namaaplikasi_$ver-kuliax-$revisipaket_$arch atau
namaaplikasi_$ver-$revisipaket~kuliax_$arch
jadi misal nama aplikasi bernama app dengan versi 0.1 maka nama
paket hasil
build di kuliax: app_0.1-kuliax-1_i386.deb atau app_0.1-1~kuliax.deb
- kernel linux: linux-image-$ver-$abi-kuliax-$target_$ver-kuliax-
$revisipaket_$arch
atau linux-image-$ver-$abi-kuliax-$target_$ver-$revisipaket~kuliax_
$arch
jadi nama paket hasil build untuk kernel Linux 2.6.30 di kuliax:
linux-image-2.6.30-1-kuliax-686_2.6.30-kuliax-1_i386.deb atau
linux-image-2.6.30-1-kuliax-686_2.6.30-1~kuliax_i386.deb
berdasarkan standar paket debian kustom yang saya tahu, kita diminta
untuk menghindari karakter "-" pada *versi paket* untuk menghindari
konflik dengan paket resmi Debian, ini dapat dilihat pada usulan kedua
dengan penggunaan karakter "~"
catatan: versi paket pada contoh kernel di atas adalah 2.6.30-1~kuliax
sementara ini kita pakai pilihan pertama, saya sedang memikirkan untuk
menggunakan pilihan kedua
ada usulan lain?
Yuda Nugrahadi
> kuliax-devel,
>
> sepertinya kita perlu melakukan standar nama dan versi terhadap paket-
> paket yang dibangun dan yang di-backport oleh Kuliax
>
> usulan nama paket deb (hasil akhir build) ada dua yang terlintas di
> kepala:
>
> - aplikasi: namaaplikasi_$ver-kuliax-$revisipaket_$arch atau
> namaaplikasi_$ver-$revisipaket~kuliax_$arch
>
> jadi misal nama aplikasi bernama app dengan versi 0.1 maka nama
> paket hasil
> build di kuliax: app_0.1-kuliax-1_i386.deb atau app_0.1-1~kuliax.deb
>
dengan cara ini apabila ada perubahan di debian/ maka akan menjadi
app_0.1-kuliax-2_i386.deb gitu ?
kalau misalnya source codenya berubah alias ada bug atau (misal) dari
upstream ada revisi akan berubah gimana ?
atau mau menggunakan cara ubuntu : XubuntuY
dimana X adalah perubahan kode dalam source sedangkan Y adalah
perubahan dalam debian/
> - kernel linux: linux-image-$ver-$abi-kuliax-$target_$ver-kuliax-
> $revisipaket_$arch
> atau linux-image-$ver-$abi-kuliax-$target_$ver-$revisipaket~kuliax_
> $arch
>
> jadi nama paket hasil build untuk kernel Linux 2.6.30 di kuliax:
> linux-image-2.6.30-1-kuliax-686_2.6.30-kuliax-1_i386.deb atau
> linux-image-2.6.30-1-kuliax-686_2.6.30-1~kuliax_i386.deb
>
> berdasarkan standar paket debian kustom yang saya tahu, kita diminta
> untuk menghindari karakter "-" pada *versi paket* untuk menghindari
> konflik dengan paket resmi Debian, ini dapat dilihat pada usulan kedua
> dengan penggunaan karakter "~"
>
berhubung belum pernah baca2 dokumen terkait yang ini, belum bisa
ngasih komentar dahulu. Pertimbangannya hanya apabila dibandingkan
antara paket lama dengan paket baru apt ga bingung :D
Akhmad Fathonih
--
Kuliax Project: http://kuliax.org
IRC: #kuliax at irc.freenode.net
Saya setuju pilihan kedua, sesuai rekomendasi dokumen. Tapi menyulitkan pemaket tidak? Atau hampir tak ada bedanya?
--
http://launchpad.navinot.com - Dukung Startup Lokal!
http://navinot.com - Slashing Web & Online Strategy
stwn
>
> dengan cara ini apabila ada perubahan di debian/ maka akan menjadi
> app_0.1-kuliax-2_i386.deb gitu ?
Iya
> kalau misalnya source codenya berubah alias ada bug atau (misal) dari
> upstream ada revisi akan berubah gimana ?
Kalau *kita* yang memodifikasi:
- modifikasi harus berbentuk tambalan/patch
- yang akan berubah $revisipaket-nya dengan changelog perubahan (dch)
apa yang dilakukan, baik *kode sumber* atau *pemaketan* (debian/)
Hasil paket: app_0.1-kuliax-2_i386.deb dengan *changelog* perubahan
pemaketan dan/atau kode sumber. Hasil modifikasi kode sumber jika
memperbaiki bug pada app dikirim juga ke upstream
Kalau ada revisi atau perbaikan dari *upstream*:
- lakukan perintah uupdate di dalam direktori lama kode sumber
- otomatis uupdate akan mengganti nama direktori ke yang baru, misal
app-0.1 akan diganti otomatis ke app-0.1.1
- periksa perubahan kode sumber yang pernah kita lakukan pada
$revisipaket sebelumnya, jika modifikasi kode sumber sudah ada di
rilis upstream maka kita dapat menghilangkan tambalan hasil
$revisipaket sebelumnya
- ubah changelog (dch) bahwa ada pemutakhiran/update dari upstream dan
informasi lain misal "modifikasi pada $revisipaket sebelumnya sudah
terintegrasi ke versi minor upstream"
Hasil build paket berupa:
- app_0.1.1-kuliax-2_i386.deb, atau
- app_0.1.1-kuliax-3_i386.deb jika kita pernah melakukan perubahan
pada $revisipaket sebelumnya (kuliax-2) kemudian melakukan
pemutakhiran dari upstream (kuliax-3)
app_0.1-1lumpia2_i386.deb
Artinya:
- perubahan dari *kita* baik pada pemaketan (debian/) dan/atau kode
sumber *hanya* mempunyai efek pada *$revisipaket*, keterangan
perubahan dimasukkan di debian/changelog (dch)
- pemutakhiran versi dari *upstream* akan mengubah $ver *dan*
$revisipaket, keterangan pemutakhiran akan ada di debian/changelog
Itu yang saya pahami, sila baca http://debian.org/doc/maint-guide/ch-update.en.html
dan koreksi kalo ada yang kurang tepat
> atau mau menggunakan cara ubuntu : XubuntuY
> dimana X adalah perubahan kode dalam source sedangkan Y adalah
> perubahan dalam debian/
Saya kira tujuan penamaan ubuntu itu adalah kalau kita lihat nama
paket, kita bisa tahu bahwa ada perubahan kode sumber dan/atau
pemaketan. Prakteknya pengguna tidak melihat hal ini, dan juga
pengembang dapat melihat changelog untuk mendapatkan informasi
berkaitan dengan perubahan yang terjadi
Karena ubuntu sudah berskala "besar", mungkin akan memudahkan proses
pengembangan. Pengembang tidak perlu membongkar paket dan melihat
changelog untuk mengetahui perubahan yang terjadi pada suatu paket
Saya lihat di Debian (lenny) ada paket-paket baru yang menggunakan
penamaan ubuntu, tapi menggantikan "ubuntu" dengan nama kode rilis
yaitu "lenny". Contoh: libavahi-client3_0.6.23-3lenny1. Mungkin
pengembang paket Debian tersebut sekaligus pengembang ubuntu :))
Kalau kita ikut cara penamaan yang terakhir, berarti kita bisa pake
$revisipaket: XlumpiaY :D
stwn
>
> Saya setuju pilihan kedua, sesuai rekomendasi dokumen. Tapi menyulitkan
> pemaket tidak? Atau hampir tak ada bedanya?
Sebenarnya bukan rekomendasi dokumen sih tapi lebih ke konvensi yang
ada di contoh-contoh dokumentasi Debian, dan juga saat kita melakukan
build ada notifikasi bahwa karakter "-" akan menimbulkan *potensi*
konflik versi dengan paket resmi Debian. notifikasi ini saya lihat di
proses build kernel
Proses perubahan $revisipaket tidak menyulitkan pemaket kok, kita
hanya perlu mikir sedikit "tadi ubah apa ya" *bagus untuk dokumentasi*
stwn
>
> app_0.1-1lumpia2_i386.deb
Hihi ada yang nggak sengaja kekirim, ini adalah contoh hasil build
jika kita menggunakan cara yang terakhir pada surel sebelumnya
> - pemutakhiran versi dari *upstream* akan mengubah $ver *dan*
> $revisipaket, keterangan pemutakhiran akan ada di debian/changelog
Ini perlu dikroscek, karena bisa jadi perubahan hanya pada $ver dengan
$revisipaket yang direset ke awal
Kita perlu memutuskan standar penamaan dan versi, mengikutinya dan
melakukan pemaketan secara *nyata*, dan jika ada yang "aneh" usulkan
dan mari kita perbaiki
stwn
>
> Kita perlu memutuskan standar penamaan dan versi, mengikutinya dan
> melakukan pemaketan secara *nyata*, dan jika ada yang "aneh" usulkan
> dan mari kita perbaiki
Saya putuskan untuk paket Kernel Linux akan menggunakan:
kuliax.X untuk $abi
patchlevel~kuliax.Y untuk $revisipaket
Jadi, hasil build paket image kernel 2.6.30 (686): linux-image-2.6.30-
kuliax.X-686_2.6.30-8~kuliax.Y_i386.deb
Catatan: patchlevel mengikuti kode sumber paket kernel Debian baik
yang resmi ataupun backports
stwn
>
> atau mau menggunakan cara ubuntu : XubuntuY
> dimana X adalah perubahan kode dalam source sedangkan Y adalah
> perubahan dalam debian/
X bukan perubahan kode dalam sumber, tapi perubahan pada *Debian*,
karena Ubuntu mengambil paket dari unstable Debian.
Jadi, misal ada paket bernama app_1.0-0ubuntu3, berarti paket app
versi 1.0 sudah mengalami 3 kali perubahan/revisi di Ubuntu, dan
perubahan ini *belum ada* di Debian (0)
stwn
>
> X bukan perubahan kode dalam sumber, tapi perubahan pada *Debian*,
> karena Ubuntu mengambil paket dari unstable Debian.
>
> Jadi, misal ada paket bernama app_1.0-0ubuntu3, berarti paket app
> versi 1.0 sudah mengalami 3 kali perubahan/revisi di Ubuntu, dan
> perubahan ini *belum ada* di Debian (0)
Ok, dengan ini kita menggunakan XkuliaxY untuk revisi paket, dengan:
- X adalah revisi Debian atau proyek upstream, dan
- Y adalah revisi Kuliax
Jika ada aplikasi_1.0-3 dari Debian maka backport aplikasi 1.0 di
Kuliax pertama kali adalah aplikasi_1.0-3kuliax1
Jika ada aplikasi_1.0 yang *belum ada* di Debian maka aplikasi 1.0 di
Kuliax pertama kali adalah aplikasi_1.0-0kuliax1
Demikian pula kernel saya ubah standar revisinya menjadi:
- kuliax.Z untuk ABI
- XkuliaxY untuk revisi paket
Jadi, build paket image kernel 2.6.30 dengan ABI 2 dan patchlevel 8
(linux-image-*-2-*_2.6.30-8) pertama kali di Kuliax:
Z = 2, X=8, Y=1
Hasilnya untuk 686: linux-image-2.6.30-kuliax.
2-686_2.6.30-8kuliax1_i386.deb
stwn
Hanya sedikit menyarikan alasan keputusan penggunaan standar versi
paket Kuliax.
Pada kasus paket yang di-backport Kuliax dari squeeze/testing ataupun
sid/unstable, saya sudah mencoba menggunakan format sebelumnya yaitu
X~kuliax.Y untuk:
1. membangun paket, contoh: aplikasi_1.0-3. Pada proses menjalankan
perintah `dch -v 1.0-3~kuliax.1` muncul pesan kesalahan bahwa versi
paket menggunakan angka yang lebih rendah (-3~kuliax.1) dari versi
paket sebelumnya (-3). Saya berasumsi versi yang dipakai dan diperiksa
sistem pemaketan Debian pada kasus ini adalah angka paling belakang,
satu (1), yang ternyata lebih kecil daripada tiga (3)
2. membandingkan paket backport Kuliax (-3~kuliax.1) dengan paket
aplikasi yang ada di squeeze maupun sid (-3). Walaupun versi paket
bagian depan backport Kuliax sama dengan yang di sid, paket tersebut
mempunyai status *dapat* di-upgrade ke sid oleh APT. Hal ini akan
bermasalah, karena jika pengguna Kuliax sengaja atau tidak sengaja
meng-upgrade maka semua dependensi di sid akan ikut terambil dan
berpotensi "merusak"
Itu kenapa akhirnya saya memilih standar revisi paket XkuliaxY, dimana
saya dapat mencoba format tersebut dengan `dch` tanpa keluhan versi
lebih rendah, dan ketika dibandingkan dengan rilis squeeze atau sid
tidak ada permintaan upgrade, karena versi paket yang ada di Kuliax
adalah versi yang lebih baru (backport squeeze/sid ke lenny).
Versi paket = 1.0-3kuliax1
Revisi paket Debian = 3
Revisi paket Kuliax = 1