[Gelistirici] ABI kıran paketler ve yeni tag hadisesi

S.Çağlar Onur caglar at pardus.org.tr
22 Mar 2008 Cmt 03:15:26 EET


Selamlar;

22 Mar 2008 Cts tarihinde, Gökçen Eraslan şunları yazmıştı: 
> Malumunuz, devel ile 2007/test depoları arasındaki fark oldukça açıldı. 
> Aslında bunun sebeplerinden biri de ABI kıran paketler ve onların 
> bağımlılıkları. Misal, devel'deki lastfm paketi yine develdeki libgpod'a 
> bağımlı olduğundan ve libgpod ABI kırdığından paketi test deposuna almak 
> güçleşiyor, çünkü amarok da libgpod'a bağlı ve onun da bu durumda yeni 
> libgpod'la, yeniden derlenmesi gerekiyor. Aynı şekilde ABI kıran bir çok 
> paket var devel depomuzda.
> 
> ABI kıran paketler için türlü taklalar atmak yerine daha önce de çok kez 
> konuşulan ABI kıran paketler için pspec.xml'lere tag ekleme hadisesine 
> geliyor konu. Bunun için önerileri değerlendirelim ve mümkünse artık bunu bir 
> sonuca bağlayalım diyorum.
> 
> pspec.xml'de, Update tag'ine eklenecek bir attribute ya da ayrı bir tag, 
> (örneğin BreaksABI) buildfarm'da, paketin ters bağımlılıklarının yeniden 
> derlenmesine neden olursa, sanırım problem çözülmüş oluyor. Böylece misal, 
> libgpod'a gelen bir güncellemenin ardından, libgpod'un ters bağımlılıkları 
> amarok, lastfm vs. tekrar derleniyor ve kullanıcının karşısına güncelleme 
> olarak çıkıyor. Tabi bu durumda, kullanıcının sadece libgpod güncellemesini 
> seçip, ters bağımlılıklarını bırakmasına izin verilmemesi gerekiyor. Yani o 
> anda, pisi için ABI kıran paket ve ters bağımlılıklarının tek paket gibi 
> davranması, ya hep birlikte güncellenmesi ya da hiçbirinin güncellenmemesi 
> gerekiyor. Zira herhangi birinin güncellenmesi o paketi ya da bir 
> bağımlılığını kararsız bir şekilde bırakıyor.
> 
> Öneriler/fikirler?
 
Bu yazdıkların hem farm hem de PiSi için doğru fakat bir şartla :). 

ABI kırabiliyoruz diye her an bunu değiştireceksek bu çok ciddi politika ve teknik sorunları da yanında getirecek. N zaman önce böyle bir tag önermemin nedeni güvenlik güncellemelerinde (eğer backport zorluyorsa) ve dağıtım major sürüm güncellemelerinde bunu kullanmak idi, verdiğin örnekte libgpod ve amarok mesela bu sürecin dışında tutulmalı tabi politika olarak halen kararlı dağıtım x,y ve z sunar bundan ötesine yapacak bir şey duruşumuzu değiştirmeyecek veya Redhat Enterprise gibi her önümüze geleni backport etmeyeceksek.

Ve böyle bir tag tanımladığımızda kullanımını liste veya -stable ekibi veya sürüm yöneticisi onaylamalı gibi kısıtlayıcı kararlar da almalıyız ki mesela ben bir anda glibc-2.7 güzelmiş du bi BreakABI yazıp salayım demiyeyim.

2 YKR
-- 
S.Çağlar Onur <caglar at pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
-------------- sonraki bölüm --------------
A non-text attachment was scrubbed...
Name: kullanılamıyor
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20080322/9fee3de8/attachment-0002.pgp>


Gelistirici mesaj listesiyle ilgili daha fazla bilgi