[Gelistirici] [paketler-commits] r41983 - in devel/system/base/baselayout: . files

[S.Çağlar Onur]

Selamlar;

29 Şub 2008 Cum tarihinde, paketler-commits at pardus.org.tr şunları yazmıştı: 
> Author: caglar
[...]
> Log:
> Sync with SVN, and 
> 
> <BIG FAT WARNING>
> 
> From now on baselayout depends system.base component not individual packages. It has to be the first package installed into system. All these dependencies are hacks for say new postInstall etc. which will be handled PiSi or another way invented after that commit :P
> 
> </BIG FAT WARNING>

Bu ve bir önceki udev commitinin meali şöyle;

Bugüne kadar (nasıl olduğunu anlamadığım bir şekilde) baselayout'un kurulan ilk paket olmasını sağlamak için elle çözdüğümüz dep. ağacında udev'in bir çok paket tarafından istenmesi gerçeğine dayanarak o zaman udev de baselayout istesin ilk o kurulsun yapmışız. Fakat değişen bağımlılıklar ile birlikte baselayout paketi ilk değil atıyorum 10. sırada da kuruluyor olabilir ve bu atıyorum 0700 hakkı ile oluşması gereken /root klasörünün atıyorum ccache postInstall'unda /root/.ccache yaratırken 755 ile oluşması gibi acayip sonuçlar doğuruyormuş.

Baselayout ideal dünyada (biraz sonra içine gireceğiz) _hiç bir_ pakete bağımlı olmamalı çünkü özünde her paket ona bağımlı (glibc gibi) bu yüzden (eski paketteki bağımlılıklar yüzünden) chroot içine kurulumlarda mesela baselayout kurulan son paket oluyordu.

Fakat baselayout'un kurulan _ilk_ paket olmasını sağlamak için system.base içindeki her paketin baselayout'a bağımlı olmasının çözüm olduğunu düşüneniniz var ise, dıııııt, yarışmayı kaybetti :). Bazen (baselayout tarihi gösteriyor ki) postInstall'daki örneğin syntax değişiklikleri sebebi ile ___çalışan___ sistemde baselayout'un ilk kurulan paket olmaması gerekiyor. Yani;

chroot içine kurulumlar (buna YALI da dahil)

Kurulan ilk paket baselayout olmalı aksi halde çok acayip sonuçlar doğurabilir

çalışan sistemde güncellemelerde (pisi up)

postInstall'u çalıştırılan son paket olmalı aksi halde örneğin değişen postInstall syntax'ı sebebi veya yeni eklenen model sebebi ile postInstall çalıştırılamayabilir gibi sonuçlar doğurabilir. Fakat bu varsayım şu varsayımı da yanında getiriyor, bu durumda da başka bir paketin veya paketin postInstall'unun baselayout içinden gelen herhangi birşeye/modele veya postInstall sonunda ortaya çıkan hedeye bağımlı olmaması gerekiyor.

Bunu daha önce sağlayamadık, örneğin users modeli geldiğinde yeni baselayout öncesinde yeni comar-api kurulsun diye pakete dep. eklemişiz, arkasından yeni eklenen kullanıcı için (örneğin pnp) postInstall'unda iş yapan başka bir paket baselayout'dan sonra postInstall çalıştırsın diye bir dep. daha eklemişiz derken işler karışmış.

Çözüm önerim şöyle;

Ya "başka bir paketin veya paketin postInstall'unun baselayout içinden gelen herhangi birşeye/modele veya postInstall sonunda ortaya çıkan hedeye bağımlı olmaması gerekiyor." kuralını kabul edeceğiz ve bu duruma düşersek bu sorunu başka bir çözümle çözeceğiz 

veya 

Yeni bir tag, ne bileyim index'e giren birşey veya PiSi'nin orasına burasına elleyerek bu durumu çözen bir çözüm üreteceğiz.

Yorum/öneri/kaçırdığım bişiy/ekleme/çıkarma/hede/hödö/jant/manifolt/şarap/peynir?

-- 
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/20080229/2fa87f8a/attachment-0002.pgp>