[Gelistirici] Ciddi sorunlar, sesli düşünceler

[Fatih Aşıcı]

On Tuesday 04 January 2011 17:01:34 Gökçen Eraslan wrote:
> Selamlar,

Selamlar,
 
> 0- Skype paketi sadece 32 bit dağıtıldığı için (Ubuntu için hazırlanmış 64
> bit de aslında 32bit), 64bit depoya, Skype'ın bağımlılığı olan 32bit
> paketleri(alsa-lib vs) de almamız gerekiyor ve bunların 64bit olanlarıyla
> çakışmadan, mutlu mesut yaşayabiliyor olmaları lazım. Wine için de benzer
> bir durum var, 64bit Pardus'ta, 32bit Windows uygulamalarını wine'da
> çalıştırabilmek için yine, wine ve bağımlılıklarının da 64bit depoya
> alınması gerekiyor. İstersek şu anda *sadece 32bit depoya* wine ve skype'ı
> alabiliriz ExcludeArch sağolsun, fakat bu çözüm olmaz. Workaround bile
> olmaz.

32 bit farmda derlenmiş paketleri dönüştürmek bence sağlıklı bir şey değil. 
Zaten bu yöntemde bilinen sorunlar da var. Örneğin gtk'nın config dosyalarında 
modüllerin tam yolları geçiyor. Bunları nasıl lib32'ye çevireceğiz? Bu tür 
sorunlar yüzünden Arch Linux'un bu yöntemi bırakıp farklı bir depo açtığını 
biliyorum.

Bence 32bit paketleri ayrı source paketlerden çıksın. Gerekmedikçe bazı 
özellikler bu paketlerde etkisiz hale getirebilir. Böylece gereksiz 
bağımlılıkların bağımlılıklarını paketlememiş oluruz. Bu paketlerin ayrı bir 
depoda yer alıp almamasını tartışmamız lazım.

Bu arada skype için Fatih Arslan ile beraber bugün/yarın bir şeyler 
deneyeceğiz.
 
> 1- Pisi delta desteğini açmamız gerekiyor, hem delta'yı test etmeye devam
> ederiz, yeni pisi ile ilgili bir sorun olmadığından emin oluruz hem de
> bonus olarak insanlara daha küçük boyutlu güncellemeler gider. Bunun için
> Fatih'in sanırım pisi'de yapacağı şeyler var.

Aslında üzerimdeki tüm işleri bırakıp pisi'ye yönelmem lazım. delta ile ilgili 
eski farmda bazı kısımlar vardı. Bunların yerinin farm olmadığını düşünerek 
attık. Bazı şeyleri (build sonrası otomatik delta oluşturma gibi) pisi kendisi 
yapabiliyor; fakat bazı şeyler eksik. Bunlar:

  * Bazı paketlerin deltasının üretilmesini engellemek
  * Sürüm günü depoda bulunan paketler için her zaman delta üretilmesini
    sağlamak.

Pisi'nin bu bilgileri alacağı dosyaların formatına ve yerine karar vermem 
gerekiyor.
 
> 3- OpenOffice/LibreOffice extension'larıyla (zemberek ve OO paketinden
> gelenler) ciddi bir sorunumuz var. OpenOffice-LibreOffice geçişinde, önce
> OO silinip LO geliyor, ardından da aynı işlem eklentiler için yapılmaya
> çalışılıyor fakat bu işlem için gereken unopkg programı artık yeni LO'dan
> geldiği için eklentiler kaldırılamıyor/kurulamıyor. Benim daha önce
> eklenti betiklerine sorunların gözden kaçmaması için eklediğim strict
> kontroller yüzünden direk exception alınıyor. Bunun en kötü tarafı ise, ne
> kadar güncelleme gelirse gelsin kullanıcıların makinesindeki preremove'lar
> çalıştığı için, bunun şu anda pratik bir çözümünün olmaması. Bunu da
> acilen çözmemiz gerek. Aynı sorun, Kurumsal2'de de mevcut bu arada.

Pisi'nin neden bir preInstall metodunun olmadığını anlamakta zorlanıyorum. 
Bazı şeyleri hep ihtiyaç duyunca gerçeklemişiz. Oysa en basitinden rpm'e 
bakılsa bu tür şeylere zamanı gelince ihtiyaç duyulduğu anlaşılabilirdi. 
Burada da pisi tarafında yapılması gereken önemli işler var.

Bir diğer çözüm yeni pisi'de preRemove vs hatalarını ignore etmek olabilir. 
2011'e geçilirken önce yeni pisi'ye geçileceği için yukarıdaki senaryoyu 
kurtarabiliriz belki.
 
> 5- Pae kernel hazırlayacak mıyız? Her ne kadar 64 bit sürümümüz olsa da,
> 64bit desteği olmayan ama >= 4G ram kullanan kullanıcıların daha mutlu
> olması için güzel olur.

Aslında sadece tek bir template kullanıp aynı source paketlerden otomatik 
olarak default ve pae kernel'e ait paket dosyalarının üretilmesini 
sağlayabiliriz belki. Uğraşmak/düşünmek lazım.
 
> 6- zorg komutunun akıbeti ve konsoldan sürücü değiştirmeyi tartışmamız
> gerekiyor. Fatih sanırım zorg komutunu kaldırmayı planlıyor, bana
> sorarsanız da daha önceden kullanıcılara sunduğumuz nimetler olarak
> bakarsak, vazgeçmek için sıkı nedenlerimiz olmalı. Fatih?

Statik yapılandırmadan kurtulmak istiyorum. Kullanıcılar bunu yanlış şekilde 
kullanıp başlarına daha fazla iş açıyorlar.

Yeni altyapıda "sürücü seçimi" yerine "sürücü tercihi" hakim. Yani "Şu 
sürücüyü kullan" demek yerine "Şu durumda şu sürücüyü tercih et" diyoruz. Bu 
donanım değişikliklerinde yeni donanımın düzgün bir şekilde kullanılabilmesini 
sağlıyor. Üstelik eski donanıma ait tercihler silinmiyor. Böylece birden fazla 
ekran kartı olan bir sistemde yapılandırma değişmiyor.

Yeni altyapıda xorg.conf da yazılmıyor (nvidia-settings ve catalyst 
kullanıyor). xorg.conf'un olmaması X sunucusundaki otomatik algılama kodunun 
çalışmasını sağlıyor. Bu yüzden bu dosyanın olmaması daha iyi.

Artık KMS sürücülerimiz var. Bazı seçimlerin initramfs aşamasında yapılması 
gerekiyor. KMS sürücüsü bir defa yüklendiği zaman nvidia ve fglrx sürücüleri 
çalışmıyor. Diğer taraftan KMS'nin durumu kernel parametrelerine göre de 
değişebiliyor. Dolayısıyla statik bir yapılandırma belirli kernel 
parametreleri verildiğinde başarısızlığa uğrayacaktır. Bu yüzden artık 
xorg.conf ile uğraşmayıp kernel parametrelerini değiştiriyoruz sadece. Örneğin 
blacklist=radeon parametresi KMS sürücüsünün yüklenmemesini sağlıyor. Bu da 
X'in varsa fglrx'i yoksa radeon'u kullanmasını sağlıyor.

Yukarıda anlattığım nedenlerden dolayı zorg'un --driver parametresinin artık 
bir anlamı kalmıyor. Kullanıcıların böyle bir seçeneği kullanmasını 
istemiyorum. Çünkü bu, birçok soruna yol açabilen bir şey. Zaten 
kullanıcıların konsol kullanmasını istemiyoruz. Deneyimli olan kullanıcı 
kendisi xorg.conf yazabilir (örnek bir xorg.conf'u pakete alabilirim). Klavye 
ayarları da artık /etc/X11/xorg.conf.d/10-keyboard.conf dosyasından 
yapılabiliyor. Deneyimli bir kullanıcı bunu rahatlıkla düzenleyebilir.

Yoğun istek gelirse dummy bir zorg betiği koyabilirim tabi.
-------------- sonraki bölüm --------------
A non-text attachment was scrubbed...
Name: kullanılamıyor
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20110105/ae08866e/attachment-0002.pgp>