Homebrew 6.0.0 yayınlandı

• Tüm meta verileri tek bir indirmede birleştiren dahili JSON API varsayılan hale getirildi; böylece güncellemeler hızlandı ve ağ iletişimi azaldı
  • Mevcut HOMEBREW_USE_INTERNAL_API opt-in değişkeni deprecated olarak işaretlendi
• Linux’ta Bubblewrap sandbox uygulanarak build, test ve postinstall adımları macOS ile aynı şekilde izole çalıştırılıyor
• Kullanıcı anketi doğrultusunda ask modu geliştiriciler için varsayılan olarak değiştirildi; brew install ve brew upgrade sırasında bağımlılık özeti ile onay istemi gösteriliyor
• brew bundle içinde paralel formula kurulumu artık varsayılan olarak otomatik çalışıyor; ayrıca npm ve krew genişletmeleri ile Windows winget desteği eklendi
• brew leaves komutunda yaklaşık %30 hızlanma dahil olmak üzere başlangıç ve yükseltme süreçlerinde genel performans iyileştirmeleri yapıldı
• macOS 27 (Golden Gate) için ilk destek eklendi
  • Intel desteğinin sona ermesiyle birlikte macOS Intel x86_64, Eylül 2026’da Tier 3 seviyesine düşecek ve Eylül 2027’de tamamen destek dışı kalacak
• 3 güvenlik tavsiyesi yayımlandı ve düzeltildi (HTTPS→HTTP yönlendirme atlatması, .pkg postinstall sırasında root kod çalıştırma, /var/tmp plist sahipliğinin ele geçirilmesi)
• npx benzeri yeni komut brew exec ile kurulu paketlerdeki açıkları denetleyen brew vulns gibi yeni komutlar eklendi
• Ortak postinstall ve flight davranışlarını literal DSL verisi olarak JSON API üzerinden sunan install steps framework tanıtıldı; basit görevlerde Ruby dosyalarını indirip değerlendirme gerekliliği ortadan kalktı
• npm ve PyPI gibi riskli ekosistemlerde indirmelere cooldown uygulanarak upstream tedarik tarafı güvenlik riski azaltıldı

[lamanus]

Intel Mac’leri desteklemeye yetecek kaynak da yok ve GitHub Actions da artık imaj sağlamayacağından, Homebrew de buna uygun şekilde ilerlemek zorunda.

[GN⁺]

Hacker News yorumları

• GitHub'daki @bfontaine benim. 2014~2016 civarında Homebrew bakımına yardımcı olmuştum; Mike'ın 16 yıldan uzun süredir bakımını sürdürüp hâlâ yeni özellikler çıkardığını görmek beni hep şaşırtıyor

  • Eylülde 17 yıl olacak. O zaman yaptığın harika katkılar için teşekkürler, umarım iyisindir
  • Homebrew o kadar iyi ki mümkün olduğunda Linux'ta da kullanıyorum
    Linux paket yöneticilerinin çoğu, kullanıcının kurduğu paketlerle sistem paketlerini ayıramıyor; bu da iş istasyonunu temizlemeyi neredeyse imkânsız hâle getiriyor ve neyin silinmesinin güvenli olduğunu anlamayı zorlaştırıyor
    Ayrıca yerel paket yöneticileri Homebrew'dan daha yavaş güncellendiği için çoğu zaman yalnızca eski paketleri alabiliyorsunuz

• Deney olarak Homebrew+pipx+npm'den https://mise.jdx.dev/ tarafına tüm OS düzeyi geliştirme ortamımı taşıdım ve gerçekten çok iyi çalıştı
  Birçok araç doğrudan GitHub release'lerinden veya ilgili paket yöneticilerinden (uv, pnpm, go get vb.) kurulduğu için yeniden paketleme için yapıştırıcı koda da gerek kalmıyor, sürüm gecikmesi de olmuyor
  İstediğiniz herhangi bir sürümü ya da birden çok sürümü aynı anda kurabiliyor, etkin sürümü çalışma klasörüne veya ortama göre dinamik olarak değiştirebiliyorsunuz
  İlginç şekilde Mise bağımlılıkları desteklemiyor ama bu çoğunlukla sorun olmadı. Ya pnpm/uv hallediyor ya da statik binary olduğu için doğrudan çalışıyor
  Geçmişte bir Python uygulamasını Homebrew için paketlerken 50 bağımlılığı resources olarak içeri almak, hepsini ya kaynaktan derlemek ya da Homebrew'da olup olmadığını elle kontrol etmek, 5 dilin build toolchain'ini bağımlılık olarak tanımlamak ve her güncellemede CI'ın bir saatten fazla sürmesini beklemek zorunda kalmıştım; sonra da upstream güncellemesi yüzünden Homebrew'da çözülemeyen bir “build-time dependency loop” oluşmuştu
  Bu yüzden Mise'in neden “kolay yolu” seçip dil bazlı paket yöneticilerine doğrudan bağımlı olduğunu tamamen anlıyorum
  Brewfile'da yerine koyamadığım tek şey, Colima ile konuşmak için gereken Docker CLI oldu; cask tarafında ise hâlâ Homebrew kullanıyorum. Geliştirme ortamınızı denemenizi tavsiye ederim. Bugünlerde harika yeni araçlar var

  • Mise kesinlikle kendi başına ayrı bir ligde gibi görünüyor. Daha önce başka yerlerde de söylediğim gibi aqua veya asdf gibi registry'lere dayanıyor
    Homebrew paketleri için Mise kullanmak isteyenler adına https://github.com/kennyg/mise-zerobrew var
  • Bir PHP geliştiricisi olarak Mise'in desteği, Shivam Mathur'un Homebrew için yaptığı PHP paketlemesine kıyasla epey zayıf kaldı
    Zaten çoğu proje Docker kullanıyor ve yerel PHP de genelde statik analiz gibi Docker gerektirmeyen işler için kullanılıyor
    Nix kullanan birkaç projem de var; Nix diğer her şeyi küçümseyecek kadar güçlü ama genel kullanıcı deneyimi git'ten bile daha düşmanca
  • İyi bir deneyim yaşamana sevindim ama ben şahsen Mise'den Brew'a geri döndüm
    Belki benim beceriksizliğimdi ama Mise'de sorun çıkaran çok fazla paket vardı
  • Mise'i çok seviyorum ama onu sadece proje bazlı araç yönetimi veya JDK sürümü gibi işler için kullanıyorum
    Sistem genelindeki araçlar için de denedim ama Helix, NeoVim, RipGrep gibi kabaca güncel olması yeterli olan ve tam sürümü umursamadığım araçlarda iyi uymadı
  • Mise de bir ölçüde bağımlılık desteği sunuyor ama diğer paket yöneticilerinde beklendiği şekilde değil
    Mise'deki bağımlılıklar otomatik değil; hepsini elle tanımlamanız gerekiyor. Amaç, paralel kurulumların doğurduğu sıralama sorunlarını önlemek. Örneğin pipx:black kullanıyorsanız Python kurulumu bitene kadar beklemesi gerekir. Araçtaki depends seçeneği bunun için var
    Bu kasıtlı bir tasarım. Mise, Homebrew veya Nix gibi tam bir bootstrap çözümü değil; mevcut sistemin üstüne oturan bir overlay olarak tasarlandı
    Bu yüzden Python'ı Brew ile, black'i ise Mise ile yönetmek neredeyse hiçbir ek ayar gerektirmeden çalışabiliyor. Bence bu tasarım kararı büyük ölçüde başarılı oldu. Bir dezavantaj gibi gelebilir ama sonuçta kullanıcıların Mise'i kolay bulmasının en büyük nedeni muhtemelen bu

• Homebrew, değiştirilemez Linux dağıtımlarında ortamı hızlıca bootstrap etmek için harika bir yoldu
  Kullanıcı sayısı çok fazla değil ama https://formulae.brew.sh/analytics/os-version/365d/ verilerine göre Universal Blue'nun Bazzite (%1,28), Bluefin (%0,49), Aurora (%0,28) gibi işletim sistemleri varsayılan olarak Homebrew'u paketleyip sunuyor
  İlgili depo: https://github.com/ublue-os/brew

  • Kullanıcı alanı paket yöneticisi kavramı, sanki Linux'un 20 yıl önce çözmüş olması gereken bir şey gibi geliyor
    Root olmayan kullanıcı için olağan durumun “XY'yi kuramazsın ama kaynaktan derlemekte özgürsün” olması komik
    Homebrew, Mise ve Nix bugün bu boşluğu dolduruyor. Flatpak daha çok GUI uygulamaları tarafında; Snap ise... var işte
  • Bazzite'ta home-manager ile birlikte Nix kullanıyorum

• İlk kurduğum üç şey Sublime Text, Homebrew ve en güncel Bash oluyor. Zsh'a geçmeyi düşünmüyorum
  İyi araçlar bilgisayarla uğraşmayı keyifli hâle getiriyor

  • Önce Homebrew'u kurup sonra onunla Sublime ve Bash'i kurabilirsin

• Kısa süre önce Nix'ten Homebrew'e geri döndüm ve bunun üç büyük nedeni var
  Brew, sahip olduğu paketler için Nix'ten daha iyi destek sunuyor gibi görünüyor. Nix'te bazı paketler iyi bakım almıyor gibi duruyor
  Mac desteği de daha iyi. Bazı Nix paketlerinde macOS'ta işlevler kapalı oluyor; muhtemelen ilgili paket bakımcısının test için bir Mac'i olmadığı içindir
  Kullanıcı deneyimi de daha iyi
  Elbette Nix ortamlarının yeniden üretilebilirliğini ve belirli paketleri içeren bir flake'i kolayca oluşturabilme yeteneğini özlüyorum, ama genel olarak beni geri getiren Brew oldu. Yine de Nix'i hâlâ seviyorum ve iş yerinde de Nix kullanıyoruz

  • nix-darwin kullanıyorum ve Homebrew paketlerini de oradan yönetiyorum. Bir bakmaya değer
    İş yerinde Nix'i nerede kullandığınızı merak ettim. Nix'in uygun göründüğü birkaç yer var ama tam olarak işaret etmek zor
  • macOS özellik ayarlarını ve yapılandırmasını otomatikleştirebileceğini düşündüğüm için Nix'le ilgilenmiştim
    Ama genelde sadece defaults veya aradaki bir aracı çalıştırma seviyesinde kalıyordu
    Sonunda Brew'u korudum ve bash_profile içinde idempotent bir setupmac() fonksiyonu yazdım. Bash 5 kullanıyorum ve ChatGPT'nin güzel defaults komutlarını iyi bilmesi sayesinde yardım aldım
    Dotfiles içinde tuttuğum Brewfile ile birlikte, yeni hesap veya Mac kurulum sorunlarının neredeyse tamamını çözdüğüm için o kadar büyük araçlara ihtiyaç duymuyorum

• Homebrew, çalışanlar tarafından değil tamamen gönüllülerce yürütülen kâr amacı gütmeyen bir proje
  Sürekli entegrasyon, gelecekteki iyileştirmeler için gereken yazılım, donanım ve barındırma maliyetlerini karşılamak için fon gerekiyor
  Tüm bağışların kullanıcılar için daha iyi bir Homebrew yapmak adına kullanıldığı söylendiğine göre, GitHub Sponsors, OpenCollective ve Patreon üzerinden düzenli destek vermeyi düşünmeye değer
  Faydalandığım açık kaynak projelerine çok bağış yaptım ama Homebrew'u hiç derinlemesine düşünmemiştim; artık desteklemem gerek sanırım

  • Apple'ın ya da en azından Mac odaklı büyük geliştirme şirketlerinin Homebrew'a sponsor olmaması şaşırtıcı

• Homebrew'e bir tür cooldown mekanizması eklenip eklenemeyeceğini merak ediyorum
  Makinama hızlıca yeni kod dağıtma konusunda güvenmek istediğim tek şey Apple ve tarayıcılar. Çünkü tarayıcılar diğer her şeyden daha fazla güvenilmez girdi işliyor
  Bunun dışındaki vscode ve eklentileri, npm, homebrew ve otomatik güncellenen uygulamalarda birkaç gün beklemeyi tercih ederim
  Bazı istisnai 0-day durumlarında cooldown'ın atlanması gerekebilir, ama zaten bugün de kullanıcı brew upgrade çalıştırana kadar 0-day'e karşı savunmasız kalıyor

  • https://docs.brew.sh/Supply-Chain-Security sayfasında cooldown konusunu nasıl ele aldıkları ve bunun neden NPM gibi şeylerden risk profili olarak çok farklı olduğu anlatılıyor
    Ayrıca NPM/PyPI/RubyGems'ten alınıp paketlenen öğeler arasında bu tür saldırıların hedefi olabilecekler için, paketleme sırasında ve yeni sürüm güncelleme PR'ı oluşturulurken zaten cooldown uygulanıyor
  • Burada kastedilen, tedarik zinciri saldırılarına açıklığı azaltmak için --minimum-release-age veya minimumReleaseAge gibi bir özellik
    Bu tür saldırılar genellikle ihlalden sonraki birkaç gün içinde tespit ediliyor
    Bun'un örneği: https://bun.com/docs/pm/cli/install#minimum-release-age
  • Çoğu şey sürüm kanalları ile ele alınıyor. Örneğin brew set-channel stable/edge gibi
    Bu hafta Elixir 1.20 duyurusundan sonra onu denemeye sadece birkaç dakikam vardı ve Brew'un geride kalması can sıkıcıydı
    erl ve elixir başka yollarla da kurulabiliyor ve ben kişisel olarak kendi toolchain'lerini tercih ediyorum ama o anda buna değmezdi
    Brew'da bazı recipe'ler için kaynak seçenekleri vardı ya da hâlâ var; biraz gözünü kısarak bakarsan bu da esasen bir çözüm sayılır
  • Her şey rolling release, ama Homebrew'de sürümü yükseltmesi gereken kişi yazılımın yazarı değil Homebrew bakımcısı
    Yazarın Homebrew core'a PR göndermesi veya kendi Tap'ini yayımlaması istisna. Arch'ın bunu nasıl yaptığını merak ediyorum
  • Bu sürümde yer alıyor. “Cooldowns, livecheck and bumping” bölümüne bakabilirsiniz

• Homebrew'u mümkün kılan herkese alkış. Projeye destek vermeyi düşünebilirsiniz: https://opencollective.com/homebrew

• Intel desteğinin kaldırılması agresif hissettiriyor
  Mac'i sunucu olarak kullanan meraklıların neredeyse hepsi eski makineler kullanıyor ve bunların çoğu Intel. Apple'dan 1 yıl önce destek kaybedecekler
  Intel desteğinin zahmetli olduğunu ve bunun bir tercih meselesi olduğunu anlıyorum, ama Homebrew'un Intel desteğini mümkün olduğunca uzun sürdürmenin bir yolunu araması gerektiğini düşünüyorum

  • Aslında Apple meraklılarının ezici çoğunluğu Apple Silicon'a tamamen geçmiş gibi görünüyor
    Eski Mac'leri sunucu olarak kullananların yuvarlama hatasını aşacak kadar bile büyük bir grup olmadığını düşünüyorum
  • Apple kaynaklarının en azından bir kısmını Homebrew gibi şeylerin bakımına ya da bunu yapan insanlara ödeme yapmaya ayırsaydı durum farklı olabilirdi
  • Bu noktada söz konusu Intel Mac muhtemelen 2018 Mac mini civarında olurdu; yalnızca Sequoia'ya kadar çalışabiliyor ve Homebrew Intel desteğini bıraktığında o da desteğini kaybediyor
    Intel desteğine ihtiyacınız varsa MacPorts hâlâ Leopard'a kadar çalışıyor
  • --no-quarantine bayrağı desteği de kaldırıldı
    Artık sadece birkaç cask için Homebrew kullanıyorum ve mümkün olduğunca kaçınmaya çalışıyorum. CLI araçları için Nix, Home-Manager ve Nix-Darwin kullanıyorum
  • Neyse ki bu makineler Linux dağıtımı için hâlâ mükemmel

• Sabitlenemeyen zorunlu yükseltmeler yüzünden o kadar çok canım yandı ki ben şahsen Homebrew kullanmayı bıraktım.
  Şimdi habersiz bozulmaları ve zoraki eskimeyi önlemek için Mise ve MacPorts kombinasyonunu kullanıyorum.
  Üstelik Mise ile istediğin herhangi bir yeni sürüme geçebiliyorsun, ama Homebrew'da Tap'in ne zaman yükselteceğini beklemek zorundasın. llama.cpp Tap'i bazen 10 sürümde bir atlıyor.

  • Sana uyan iş akışını bulmana içtenlikle sevindim.
    Hâlâ Homebrew kullananlar için, yalnızca gerçekten gerektiğinde yükseltme yapılması ve yükseltmeden önce bunun kullanıcıya gösterilmesi için çok emek verildi; bu sürüme de dahil edildi.
  • Ben de benzer deneyim yaşayan başka biri var mı diye sormayı düşünüyordum.
    Geliştirme araçlarını kurmak için yıllardır MacPorts kullanıyorum; çok daha tutarlı ve Python'un yeni ana sürümü rastgele çıkıp insanı şaşırtmıyor.
    Homebrew'ı yalnızca MacPorts'ta olmayan Firefox, Slack, Spotify gibi uygulamaları kurmak için kullanıyorum.
    Tabii yıllardır Python için uv'ye, nodejs için pnpm'e geçmeye çalıştığım için artık benim açımdan büyük bir sorun olmayabilir.
  • Homebrew'un agresif destek kademesi sonlandırma takvimi yüzünden MacPorts'a geçtim: https://docs.brew.sh/Support-Tiers
    Her gün kullandığım iMac artık Tier-3 “defol git” kovasına girdi.
    Kullanabildiğim kısa süre boyunca Homebrew'u gerçekten çok sevdim, ama kullanmaya devam etmek için donanım yükseltme koşu bandına çıkmaya niyetim yok.
  • Çoğunu Mise'a taşımış durumdayım; kalanlar için de MacPorts'a bakmam gerekecek.
  • Nix'e de bakmaya değer. Darwin paketleme biraz dengesiz olsa da, Mac ve Linux arasında sık gidip gelmek zorundaysan platformlar arası geliştirme kabuklarına sahip olmak gerçekten harika.