[Gelistirici] Paket adları

Onur Küçük onur at pardus.org.tr
4 Tem 2010 Paz 23:07:36 EEST


On Sun, 4 Jul 2010 22:44:00 +0300
Fatih Aşıcı <fatih at pardus.org.tr> wrote:

> Bileşenleri son belirlediğimizde kriterimiz _işlev_ olmuştu. Bu
> şekilde bir değişikliğe gidersek bu kuralı bozmuş oluruz. "library"
> bileşenleri bence büyük bir hata idi. O zamandan bu zamana
> paketçilerin yaşadığı ikilemlerden bunu çıkarıyorum.
> 
> Bir paketteki dosyaların tipinin ne olduğuna (library, executable,
> vs) bakmadan konuyu ön plana çıkarmıştık. Örneğin bir paket video
> oynatma ile ilgiliyse kitaplık da olsa uygulama da olsa
> multimedia.video altına koyduk. Ancak multimedia altında library
> adında bir bileşen olması bazı paketçilerin kafasında "tüm
> kitaplıklar .library altına gitmeli" şeklinde algılandı. Oysa biz bu
> bileşene diğer bileşenlere uyduramadığımız kitaplıkları almıştık. Bu
> sorunu "library" bileşenlerinin adını "misc" şeklinde değiştirerek
> çözmeyi öneriyorum.

 library bileşeni, herhangi bir app içeriği içermeyen (app:console,
app:gui) ve sadece kitaplıktan oluşan paketleri içeriyor, bu kadar.
Sadece IsA taglarına bakarak yanlış konmuş paketleri ayıklayabiliriz.
Burada sadece programming ve system bileşenlerinin özel durumu var.

 Bileşen tasarımında başlarda library yoktu, paket yöneticisinde
uygulama olmayan paketleri GUI de gösterirken daha hızlı olması için
(IsA lara bakmadan sadece PartOf la görüntülenebilmesi için)
istenmişti, bu sebeple o hale geldi. Bunu değiştirmek istiyorsak ona
göre hareket edebiliriz, o zaman da dediğin gibi library giderse misc
konulabilir.

> -l10n ve -docs paketlerinin ayrı bir bileşende bulunmasına
> başlangıçta katılmıyordum; fakat paket yöneticisinde bu paketlerin
> "Localization" ve "Documentation" gruplarında görünmesi için ayrı bir
> bileşende bulunmaları gerekiyor. Depo kökünde bulunacak l10n
> (localization da olur) ve documentation bileşenlerine benden +1.

 ismi uzun yazmak daha iyi, daha anlaşılır oldu burada

> -devel paketlerinin bileşeni için aslında pratik bir yarar
> göremiyorum. Belki yine paket yöneticisinde programlama grubunda
> görünmesini sağlamak olabilir. Aslında dil bileşenlerine de dahil
> edilebilir bunlar. Örneğin bir -devel paketi .h dosyalarından
> oluşuyorsa programming.language.c bileşenine gidebilir. Sonuçta bu
> dosyalar C dilinde ilgili kitaplığın kullanımı için mevcut. Yani
> binding'lere benziyor biraz.

 library de olduğu gibi, arayüzde gösterme kısmını düşünerek sordum bu
kısmı. Bir -devel paketinin bence multimedia/video altında olmasının
hiç bir sakıncası yok, ama arayüzde gösterim konusundaki durum halen
geçerliyse ve öntanımlı olarak (hızdan kazanmak için) sadece
uygulamaları göstermeyi tercih edeceksek bir değişiklik yapmamız
gerekecek.

> >  Bir de, pspec de dinamik tag desteği olursa çok iyi olur. Örneğin
> > hede paketinin devel alt paketine
> > 
> >  <Dependency release="srcRelease">srcName</Dependency>
> > 
> >  gibi bir şey yazabilirsek pek çok hatayı oluşmadan çözmüş olacağız.
> 
> Bunun için keyword başında özel bir karakter kullanmak daha doğru
> olur bence.

 olur tabi, yukarıdakini attım, nasıl düzgün yapabilirsek öyle yapalım,
sentaks sorun değil

> Yine de bunu Pisi'de gerçeklemek sandığımızdan daha
> sancılı olabilir. Build aşamasında ve kaynak index'i oluşturma
> esnasında Pisi'nin bunu normal şekline getirmesi düşünülebilir.

 bence mutlaka build ve index aşamalarında normal hale dönüştürülmesi
lazım, değişken olmasını sadece pspec.xml ler için düşünelim.

> Bağımlılık olarak yazılacak paket, aslında binary paketlerden biri.
> Paket adı, sürüm ve release numaraları kadar değişken olmadığı için
> gerek yok gibi geliyor bana.

 doc için pek önemli değil ama -devel ve -l10n lerin birebir aynı
release ile uyumlu olması önemli. Örneğin bir mo dosyasında "a %s b"
olan bir değişken "a %s %s b" ye dönüşürse programın çökmesine sebep
olabilir. Keza devel de de linklenmede sorun çıkabilir. Devel
değişikliklerini yakalarız da mo değişikliklerini yakalamak daha zor.

 Bu sebeplerle devel ve l10n paketlerinin release olarak ana paketin
aynı release ine bağımlı olması gerekiyor bence.

> XML'de özellik değerleri içinde version="&srcversion;" gibi bir
> kullanım var mı bilmiyorum. Tabi illa XML raconuna uymak zorunda
> değiliz :P . version="$srcversion" yapar geçeriz mesela.

 dediğim gibi nasıl oduğu önemli değil, ama bana lazım gibi geliyor.

> Bu arada YAML'da bu iş için ek kod yazmaya gerek yok :)

 :)

-- 
 Onur Küçük                                      Knowledge speaks,
 <onur.--.-.pardus.org.tr>                       but wisdom listens




Gelistirici mesaj listesiyle ilgili daha fazla bilgi