[Gelistirici] Build numaraları

[Fatih Aşıcı]

Selamlar,

Uzun zamandır build numaralarının gereksiz olduğunu düşünüyorum. Yeni pisi'de 
debug paketleri için gerekli değişiklikleri yaparken yine build numaraları 
engeliyle karşılaştım. Debug paketleri işini bir an önce halletmek ve yeni 
pisi'yi mass rebuild öncesi depoya almak istiyorum. Bu yüzden olabildiğince 
kısa bir sürede buna karar verebilirsek çok iyi olur.

* Build numaraları ne işe yarıyor?

  Build numarası, release numarası değişmediği halde yeniden derlenen
  paketleri ayırt etmede kullandığımız ek bir sayı. Bu sayı, güncellemelerde
  release numarasından daha öncelikli. Aynı paketin aynı release numaralı
  arşivleri depo içinde bulunabilirken bir build numarası için tek bir arşiv
  bulunabiliyor. Bu ayırt edici özelliği dolayısıyla delta paketlerin
  adlarında da kullanılıyor.

  Build numaraları, bootstrap, mass-rebuild, abi/api kırılması gibi durumlarda
  çiftlik yöneticisinin işini kolaylaştırıyor. Her paket için release
  arttırmaya gerek kalmıyor.

  Build numaralarının bir işlevi de elle derlenen paketleri ayırt etmek. Bazı
  paketçiler, elle derlediği paketin güncellenmesini de istemiyor. Build
  numarası olmadığı durumda release numarasına bakıldığı için gerçekten işe
  yarıyor.

* Eee, sorun ne?

  Versiyon ve release numaralarını bağımlılıklarda kullanmak mümkün; ancak bir
  paketi diğer bir paketin belirli bir build numarasına bağımlı yapmak mümkün
  değil. Zaten source depo içerisinde herhangi bir şekilde build numarası ile
  ilgili bir bilgi mevcut değil. Bu bilgi tamamen ikili depo içerisinde
  belirleniyor.

  Build numaralarının varlık sebebi olan bootstrap, mass-rebuild, api/abi
  kırılması gibi işlemlerde birbirinden tamamen farklı / birbiriyle uyumsuz
  paketler üretiliyor; ancak sonuçta oluşan paketler aynı release numarasına
  sahip. Tek farklılık build numaraları; ancak onlar da bağımlılık
  ilişkilerinde kullanılamıyor. Özellikle alt paketler arasında bu ilişkilerin
  kurulamaması büyük bir sorun.

  Kullanıcı tarafında da herhangi bir changelog gösteremediğimiz paket
  güncellemeleri sunuyoruz. Güncelleme listesinde paketin eski ve yeni sürümü
  aynı görünüyor.

  Pisi kodunda da çelişki yerler var. Kimi yerde güncelleme eylemleri
  (revDepUpdate, sysRestart, ...) release numarası değişmediğinde de dikkate
  alınıyor. Kimi yerde ise dikkate alınmıyor. Açıkçası hangisinin doğru
  olduğu da paketten pakete değişiyor.

  Build numaraları paket adlarında da tutarsızlığa yol açıyor. Bazı paketlerde
  build numarasının olmaması, programlama açısından parse etmeyi 
  zorlaştırıyor.

* Debug paketleri ile ilgili değişikliği engelleyen ne?

  Paketler her derlendiğinde debug bilgileri değişiyor. Bir hede-dbginfo
  paketinin son hali ancak hede paketinin son hali için kullanılabilir.
  Build numaralarını bağımlılık ilişkilerinde kullanamıyor olmamız yüzünden 
  paketlerin son hallerinin kurulu olmasını garantileyemiyoruz.

  Debug paketleri çok büyük ve değişken. Bu yüzden ayrı bir depo yerine normal
  depoda debug adında bir alt dizine koymayı ve pisi'de debug paketleri için
  install-debug şeklinde ayrı bir komut ile index'e girmeyecek bu paketleri
  kurmayı düşündüm. İş sadece hede-1.0-2-3.pisi için debug dizini altındaki 
  hede-dbginfo-1.0-2-3.pisi dosyasını indirip kurmaktan ibaret olacaktı; ancak
  build numaralarının aynı olmak zorunda olmadığını atlamışım. Eski sürümden
  bir kitaplık çıkmaz da yeni sürümde bir kitaplık çıkmaya başlarsa debug
  paketi yeni sürümden itibaren çıkmaya başlayacak. Bu da debug paketinin
  build numarasının geri kalmasına yol açacak.

  Yukarıda anlattığım yöntem debug paketleri için delta kullanımını da
  engelliyordu. O yüzden rafa kaldırdım. Debug paketleri debug dizini altında
  ayrı bir index'e de sahip olmalı ve delta özelliğinden de faydalanabilmeli.

  Debug depolarını sisteme öntanımlı olarak ekleyip disabled halde
  tutabiliriz. Yum'daki yönteme benzer şekilde

  pisi --enable-repo=pardus-dbg install libpng-dbginfo

  gibi bir komutla debug deposunu geçici olarak etkinleştiren bir parametre de
  düşünebiliriz.
 
* Sağladığı kolaylıkları kaybetmeyecek miyiz?

  Yeni pisi'de kullanmaya başladığımız reverseDependencyUpdate özelliği ile
  ABI kırıldığında tüm ters bağımlılıkların güncellenip release artırılması
  kararını almıştık. Dolayısıyla build numaralarının varlık sebeplerinden
  birinin iyi bir yöntem olmadığının zaten farkına vardık.

  Mass-rebuild işlemlerinde diğer dağıtımlar release arttırmayı tercih ediyor.
  Kullandığımız dosya formatlarını düşünürsek bizim bu tür işlemleri betik
  kullanarak yapmamız daha kolay.

  Bootstrap sırasında ise etkin olarak kullanılan bir depo olmadığı için dosya
  adlarında bir değişiklik yapılması şart değil.

  Elle derlenen paketlere gelelim. Diğer paketleme sistemleri yanılmıyorsam
  paketin derlendiği sisteme ait bir bilgi tutuyor (hostname benzeri). Bu tür
  bir bilgi elle derlenen paketleri ayırt etmeye yetecektir. Elle derlenen
  paketlerin güncellenmesini istemeyen paketçilerin kullanması gereken yöntem
  ise paket adlarını blacklist'e yazmak.

* Bu değişiklik şu an için biraz büyük değil mi?

  Pisi'de fazla bir değişiklik beklemiyorum. Dosya adlarında mimari ve dağıtım
  kısaltması ekleyeceğiz zaten. Buna bağımlı betikleri zaten değiştireceğiz.
  Delta paketlerinin adlarında ise build no yerine release no kullanacağız.

  Bunların dışında buildfarm'da küçük bir değişiklik gerekecek. Farm, bir
  paketi derlemeden önce depoda aynı release'e sahip bir paket olup olmadığına
  bakacak. Eğer yoksa paketi derleyecek. Hatta farm "svn diff" çıktısını parse
  etmek zorunda da kalmayacak. Paketçiler rahatlıkla "Take over" commitleri
  yapabilecek.

  Kısacası, çok büyük bir kod değişikliği önermiyorum. Üstelik sonunda debug
  paketlerini de kolay bir şekilde kullanabileceğiz. Özellikle daha temiz ve
  kaliteli bir pisi'ye sahip olacağımız için benim çok işime gelecek :)

Fikirleriniz?