Selamlar, 2010/8/11 Devrim GÜNDÜZ <dev...@gunduz.org>
> Fedora ve CentOS'da (daha doğrusu EPEL) 50+ paketi geliştiren birisi > olarak yazıyorum: Bu yazdıklarınızın olması tabii ki teknik olarak > olasıdır. Ancak paket kontrol sürecinde bunların gözden kaçması pratikte > çok zor. İmkansız demiyorum, ama bu yazdıklarınız da CentOS'un sık > karşılaşılan bir derdi gibiymiş gibi anlaşılıyor -- ve derdim de bu. > > Bu kadar paket oluşturan ve uzun süredir bu işle uğraşan birinin RPM yönetiminin ideal olduğunu iddia etmesi beni şaşırtır. Üç dört sene kadar CentOS tabanlı ticari bir güvenlik dağıtımının geliştirilmesinde çalıştım. Kaynak kodunu kendi oluşturduğumuz onlarca paket, upstreamden farklı farklı paketlediğmiiz yüzün üzerinde paket vardı. Bunlar birkaç yüz farklı müşteride kesintisiz çalışıyordu ve periyodik güncelleniyordu. Önceki postta yazdıklarımın hepsi başıma gelmiş şeyler. Yazdıklarımdan CentOS veya Redhat kötüdür kullanmayın gidin X kullanın gibi anlaşılıyorsa yanlış anlaşılıyor. Şu anda bu tip bir iş yapacak olsam deneyimim bu yönde olduğu için gidip gene CentOS kullanırım sanırım. > > Yapılandırma dosyalarında değişiklik durumuna göre .rpmnew .rpmsave > > dosyaları oluşursa bunları elle halletmek gerekebiliyor. > > Bu ne demek? Elle neyi hallediyoruz? > Bunun ne olduğunu bildiğinizi sanıyorum. > > Update sonrasında paketteki program ya da servisin yeni sürümünde > > desteklenmeyen yapılandırma parametresi varsa veya format değişmişse > > olay iyice şenleniyor. > > *CentOS* deposunda böyle birşey olamaz. EPEL ya da RPMForge > kullanıyorsanız, evet olabilir. Harici depoları kullanmak sizin > sorumluluğunuzda. > > Sadece Apache, PHP, Mysql, PostgreSQL vb. gibi sık kullanılan paketleri kurup kullanan normal bir sistem yöneticisini bu sıkıntıları yaşama olasılığı tabiki düşüktür. Ancak standart repoda da hatalar olabiliyor. Ayrıca daha güncel sürüm, tanınmayan donanım, dağıtımda olmayan yazılım vb. nedenlerle çoğu makinada ihtiyaca göre standart repo dışından paket kurulması gerekebiliyor(Linux'u esnekliği için kullanıyoruz sonuçta). Sorun sorumluluğun kimde olduğu değil araçların mümkün olduğu kadar az sorun yaratması. > > Kurulu dağıtımın paket stabilitesi bir kere bozulduktan sonra > > düzeltmek zor olabiliyor. > > Örnek rica ediyorum. > > Biraz fantastik bir örnek olacak ama glibc paketinin yum ile dependencyler dolayısıyla update olması sonrasında rpm dahil birçok komutun çalışmadığı bir durum hatırlıyorum. > -- > Devrim GÜNDÜZ > PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer > PostgreSQL RPM Repository: http://yum.pgrpms.org > Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr > http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz > > _______________________________________________ > Linux-sunucu E-Posta Listesi > Linux-sunucu@liste.linux.org.tr > > Liste kurallarını http://liste.linux.org.tr/kurallar.php bağlantısından > okuyabilirsiniz; > > Bu Listede neden bulunduğunuzu bilmiyorsanız veya artık bu listeden gelen > e-postaları almak istemiyorsanız aşağıdaki bağlantı adresini kullanarak 1 > dakika içinde üyeliğinizi sonlandırabilirsiniz. > https://liste.linux.org.tr/mailman/listinfo/linux-sunucu > > -- H Özgür Batur
_______________________________________________ Linux-sunucu E-Posta Listesi Linux-sunucu@liste.linux.org.tr Liste kurallarını http://liste.linux.org.tr/kurallar.php bağlantısından okuyabilirsiniz; Bu Listede neden bulunduğunuzu bilmiyorsanız veya artık bu listeden gelen e-postaları almak istemiyorsanız aşağıdaki bağlantı adresini kullanarak 1 dakika içinde üyeliğinizi sonlandırabilirsiniz. https://liste.linux.org.tr/mailman/listinfo/linux-sunucu
