[Gelistirici] 2009 çiftliği hazır a.k.a. fire in the hole

[Fatih Aşıcı]

03 May 2009 Pazar günü (saat 18:02:18) Barış Metin şunları yazmıştı:
> Bunu anliyorum, optimize etmek icin paketcinin isini zorlastiriyoruz
> demem bu yuzden. Aradaki B bagimliligi ile C'den A'ya ulasilabilir ve
> detayina bakmadan gerektiginde A'nin guncellemesi tetiklenebilir. Biz
> gerekmedigi durumlari elemek icin bir kural koyuyoruz. Oysa
> bakacagimiz yalnizca ldd ciktisi ise bunu rahatlikla otomatik
> yapabiliriz.

Yanlış anlamadıysam pisi'nin build sırasında tüm ikili dosyaların doğrudan 
linklediği kitaplıkları bulup build ve runtime bağımlılıklara eklemesini 
öneriyorsun? Aksi takdirde sadece pspec'teki bağımlılıklardan yola çıkılarak 
A'nın güncellenip güncellenemeyeceğine (C'yi A'ya bağımlılık yazmazsak) karar 
vermek imkansız.

Ben yine de bu bağımlılıkların getireceği iş yükünün çok fazla olmayacağını 
düşünüyorum.

> Bir de 'reverseDependencyUpdate'in asil kullanim amacini tam
> kestiremedim aslinda. Yalnizca ABI/API kirildiginda ters
> bagimliliklari guncellemek icin mi kullanacagiz? Ters bagimliliklari
> guncellemeyi gerektiren tek sorun bu degil sanirim.

Evet, tek sorun o değil. Mesela geçende zorg/display-manager/ati-drivers 
üçlüsünün birlikte güncellenmesi gerekti. ati-drivers'a display-manager 
bağımlılığı yazamazdık. display-manager'a da ati-drivers'ı. O sırada 
reverseDependencyUpdate düzgün çalışıyor olsaydı zorg paketinde kullanacaktık.

> Calisma zamani bagimliliklari yalnizca baglanilan kutuphaneler ile
> sinirli degil. Zaten baglanilan kutuphanelerin bir listesini cikartip
> bagimlilik olarak eklememizi kolaylastiran bir aracimiz da vardi bir
> ara.

Evet vardı; ancak o sıralar --as-needed kullanamadığımız için ikili dosyalar 
gerekli gereksiz her kitaplığa bağlanıyordu ve yukarıdaki senaryo için A hemen 
hemen her koşulda güncellenmek zorunda kalıyordu. Ama şimdi böyle bir 
zorunluluk yok. Bu avantajı değerlendirmek için bağımlılıkları daha açık 
yazmak gerekiyor.