[Gelistirici] [Stable] [2008] programming/libs/neon
Ekin Meroğlu
ekin at pardus.org.tr
10 Ağu 2008 Paz 22:31:08 EEST
İnanç bey,
Sunday 10 August 2008 tarihinde, İnanç Yıldırgan şunları yazmıştı:
> Version bump.
Bu sürüm yükseltme işlemi, /usr/lib/libneon.so.26 --> /usr/lib/libneon.so.27
geçişi getiriyor, neon paketinin ters bağımlılıkları olan openoffice ve
subversion paketlerini (en azından) kırıyor.
Pardus 2008 sürümü çıktığından beri 2008 deposuna commit hakkının kısıtlanıp
her güncellemenin kararlı depoya girmemesinin sebebi, benim merge işini
anlamsız derecede çok sevmem değil maalesef - kararlı bir ürünün (Pardus
2008) kararlılığını bozabilecek hamlelerden kaçınma, bir sonraki sürüme giden
geliştirme faaliyetleri ile kararlı sürümü ayırma zorunluluğumuz.
Kararlı depomuzun bir güncelleme politikası var [1] ve ilk birkaç kuralı
şöyle :
> # Kararlı depo bir platformdur, desteklediği belli bir donanım seti, belli
> bir özellik kümesi vardır, Bu kümeyi sürekli arttırmaya çalışmak platformun
> kararlığını ve bütünlüğü bozar. Her yeniliği, her güncellemeyi bu platforma
> eklemeye çalışmak yeni bir dağıtım sürümünün çıkması demektir bu sebeple
> çok gerekli olmadığı durumlarda kararlı depoda güncelleme yapmak yasaktır.
> # Kararlı depoda ABI bozmak kesinlikle yasaktır,
> # Kararlı depoda API sadece kontrollü şekilde bozulabilir, API'nin
> bozulması gereken durumlarda API'yi bozmak isteyen geliştirici paketi
> depoya göndermeden önce neden bunun gerekli olduğu geliştirici e-posta
> listesine anlatmalı ve sürüm yöneticisinden onay beklemelidir.
Evet, dağıtım olarak güncel kalalım - eskimiş bir dağıtımı ne kullanıcılar ne
de geliştiriciler sever. Ama bunu yaparken her güncellemeyi kararlı depoya
almak doğru yöntem değil.
Kaldı ki bir kütüphaneyi güncelleyen bir geliştiricinin, kütüphaneyi kendi
sisteminde - en azından ters bağımlılıklar açısından - bir testten geçirmesi,
paketteki değişikliklerden haberdar olması, sürüm takip ekibini bu konuda
bilgilendirmesi gerekir - Merge isteği yapan bir geliştiricinin kendi
sisteminde bir en azından bir revdep-rebuild çalıştırmış olduğundan emin
olmalıyız - bunu bekleyebilmeliyiz. Yoksa paket güncellemek bir betik ile
hızla yapılabilecek pspec.xml/actions.py değişikliğine gidiyor.
Özetle, depoda eski kalmış her paketi acele güncellemek yerine belli bir paket
kümesini seçip, bu paketlerin geliştiriciliğini üzerinize alarak tüm
sorunları ve yapılarıyla uğraşmanız, sonrasında ise artan tecrübenizle
birlikte zamanla daha fazla paketle uğraşmaya başlamanız daha doğru bir yol
gibi görünüyor.
Bu yazdıklarımın size denk gelmesi, sadece sizin için geçerli anlamına
gelmiyor tabii ki : Sizin ve tüm liste sakinlerinin bu iletiyi öncelikle
kararlı depo politikası ile ilgili bir uyarı, sonrasında da yeni
geliştiricilere genel bir tavsiye olarak yorumlayacaklarını umuyorum.
[1]
http://tr.pardus-wiki.org/Pardus:Depo_Politikası
--
İyi Çalışmalar;
Ekin Meroglu <ekin_at_pardus.org.tr>
... did i listen to pop music because i was miserable, or was i miserable
because i listened to pop music?... - rob [nick hornby / hi fi]
Gelistirici mesaj listesiyle ilgili
daha fazla bilgi