Ang paglipat sa RPM 6.0 ay nagmamarka ng isang mahalagang punto para sa pinakamalawak na ginagamit na package manager sa Red Hat Enterprise Linux , SUSE, at mga derivative ecosystem. Ang paglabas na ito ay kumakatawan sa pagtatapos ng mga taon ng trabaho sa pagmodernize ng seguridad, mga format ng package, at mga tool, at makikita ito sa bawat aspeto ng proyekto. Kung namamahala ka ng mga system o package software, ang pagbabagong ito ay may kaugnayan sa iyo dahil nakakaapekto ito sa kung paano mo binubuo, nilalagdaan, bineberipika, at ini-install ang mga package.
Ang paglabas ay ginawa noong Setyembre 22, 2025, kasunod ng isang kandidato sa paglabas na ngayon ay nakumpirma na bilang ang pinal na bersyon. Bukod sa pampublikong anunsyo , nagkaroon ng malaking pagsisikap sa dokumentasyon at mga pagbabago sa default na pag-uugali. Ipinakikilala ng RPM 6.0 ang pagiging tugma sa bagong v6 format at pinapalakas ang cryptographic verification , habang pinapanatili ang suporta para sa mga v4 package at inaalis ang pangangailangang i-install ang v3.
Ano ang RPM 6.0 at bakit ito mahalaga
Gamit ang RPM 6.0, pinagsasama-sama ng proyekto ang mas ligtas na mga kasanayan sa pag-sign, inaalis ang mga hindi na ginagamit na algorithm, at binubuksan ang pinto sa isang format ng pakete na handa na para sa mga modernong laki at metadata. Ang v4 na format ay 25 taong gulang na, at ang codebase ay papalapit na sa ika-30 anibersaryo nito , kaya ang malaking rebisyong ito ay kinakailangan upang makasabay sa kasalukuyang mga pamantayan at laki ng mga kontemporaryong repositoryo.
Itinatampok ng opisyal na anunsyo ang mga mahahalagang pangyayari tulad ng pamamahala ng maraming OpenPGP signature, suporta para sa mga OpenPGP v6 key at signature (kabilang ang post-quantum cryptography), at ang paggamit ng mga estratehiya upang makakuha ng malinis at napapatunayang mga release tarball. Ang pangunahing layunin ay itaas ang pamantayan para sa seguridad nang hindi binabago ang compatibility sa pang-araw-araw na gawain ng mga packager at administrator.
Mga download at footprint
Kasama sa distribusyon ang pangunahing source file na rpm-6.0.0.tar.bz2, kasama ang SHA256 checksum nito para sa beripikasyon ng integridad. SHA256 : 14abb1b944476788d90005d8d61d5d30fce80d9f0de11eb657b14e5c9ef27441.
Pangkalahatang-ideya ng mga pagbabago kumpara sa 4.20.1
- Suporta para sa v4 at v6 na pakete, na may mga detalyadong tala sa compatibility.
- Maramihang mga pirma ng OpenPGP bawat packet at suporta para sa OpenPGP v6 at PQC key.
- Pag-update ng mga dating na-import na key at paggamit ng buong fingerprint o ID sa buong cycle.
- Ang v3 package installer ay itinitigil na; maaari silang tingnan at i-extract gamit ang rpm2cpio, ngunit hindi naka-install.
- Mahigpit na pagpapatupad ng pag-verify ng lagda bilang default, pagpapataas ng seguridad ng ecosystem.
- Pangunahing rebisyon ng mga man page at dokumentasyon, na may bersyong nilalaman sa opisyal na website.
- Malinis at nabe-verify na naglalabas ng mga tarball, pagpapalakas ng reproducibility at pag-audit.
Mga pagbabago at pagpapabuti para sa pangkalahatang paggamit
Ang rpmkeys utility ay nakakakuha ng malaking impluwensya sa pamamahala ng key: pinapayagan ka na nito na i-update ang mga key gamit ang rpmkeys --import (kabilang ang pag-update ng maikli at malabong identifier sa buong fingerprint), mag-import mula sa isang pipe, mag-export gamit ang rpmkeys --export, at gumana nang pare-pareho sa iba't ibang keyring backend. Bukod pa rito, pinapayagan ka ng rpmkeys --rebuild na muling buuin ang mga nilalaman ng keyring at lumipat sa pagitan ng mga backend, at ang mga paghahanap ng key ay hindi na case-sensitive ngayon.
Ang rpmsign ay sumusulong din nang malaki: maaari na itong lagdaan gamit ang GnuPG o Sequoia-sq, na kinokontrol ng macro na %_openpgp_sign. Hindi na pinapalitan ng subcommand na rpmsign –addsign ang mga umiiral nang lagda; bilang default, nagdaragdag ito ng anumang bilang ng mga lagda sa mga v6 package, at gayundin sa mga v4 package kung ang –rpmv6 ang ginagamit. Sa kabaligtaran, pinapalitan ng rpmsign –resign ang lahat ng nakaraang lagda ng bago.
Para sa mga query, idinaragdag ang mga extension ng tag tulad ng rpmformat (upang matukoy kung ito ay v3, v4, o v6) at openpgp (para sa pamamahala ng lahat ng OpenPGP signature). Ang :hashalgo formatter ay isinasama upang ipakita ang mga pangalan ng hash algorithm, at ang –filemime alias ay lumalabas para sa pag-query sa uri ng MIME para sa bawat file. Ang terminolohiya ay inistandardisa sa mga mensahe: Ang OpenPGP ay palaging ginagamit, at ang mga v3 header at payload signature ay minarkahan bilang legacy.
Bagong function ng pagkalkula at pag-aayos ng bug sa RPM 6.0
Kinakalkula ng isang bagong function ang isang maaaring i-configure na hanay ng mga buod habang nag-verify at sine-save ang mga ito sa RPM database, na tumutulong upang matukoy ang source package file. Maraming isyu sa operasyon ang nalutas na : ang mga error sa scriptlet ay nakakaapekto na ngayon sa transaction result code; ang ilang mga nabigong trigger ay nakakaapekto sa mga kaugnay na operasyon; at ang mga isyu sa `--hash`, `--percent`, at `--test` kasabay ng `--restore` ay naayos na.
Ang mga bug tulad ng segfault at mga tagas sa rpmgraph (ang hulaping ginagamit ng rpm2archive para sa tar at cpio) ay naayos na, at ang mga man page ay sumailalim sa isang malaking pagbabago sa pagkakasulat: isang pare-parehong istilo na may mga halimbawa, mga bagong pahina para sa mga bahagi at format , paglilipat ng mga utos ng gumagamit sa seksyon 1, at pagsakop sa mga dating hindi dokumentadong aspeto. Kasama sa dokumentasyong may bersyon sa opisyal na website ang mga man page, isang manwal ng sanggunian, at dokumentasyon ng API.
Pag-iimpake at pagbuo ng pakete
Maaari na ngayong bumuo ang rpmbuild ng dalawang magkaibang format na kinokontrol ng %_rpmformat macro (mga halagang 6 o 4). Bukod pa rito, pinapagana ang self-signing sa proseso ng pagbuo kung ang %_openpgp_autosign_id ay tinukoy, at ang rpm-setup-autosign tool ay naidagdag upang mapadali ang configuration na ito.
Sa mga macro, idinaragdag ang %{span:…} upang mapadali ang mga multiline na kahulugan at ang %{xdg:…} upang suriin ang mga XDG base path. Isinama ang suporta para sa arkitektura ng E2K , kasama ang isang serye ng mga pag-aayos: pagkakasunud-sunod ng font at patch sa header, ang Lua glob na sumusunod sa c argument, pagpapatunay ng arkitektura sa tamang punto, pagtanggap ng mga seksyon ng %prep na partikular sa mga build system, at mga pag-aayos sa mga check-rpath kapag ang RPATH at RUNPATH ay magkakasamang ginagamit.
Naayos na ang memory leak sa `rpmbuild --shell`, ang regression sa bersyon 4.20 sa `rpmbuild -rs` na may mga direktoryong wala, at ang karagdagang line break sa `rpm --eval`. Naayos na rin ang segfault para sa invalid dependency generator output sa multi mode , at naalis na ang patakarang `brp-elfperms`. Panghuli, naalis na ang hindi na ginagamit na switch na `--nodirtokens` mula sa `rpmbuild`.
Mga Pagbabago sa API
Sa lugar ng keyring, idinagdag ang mga function para sa pag-iterate at pamamahala ng mga key: rpmKeyringInitIterator, rpmKeyringIteratorNext, rpmKeyringIteratorFree, rpmKeyringVerifySig2, rpmKeyringLookupKey, at rpmKeyringModify . Para sa rpmPubkey, idinagdag ang mga accessory tulad ng rpmPubkeyFingperint, rpmPubkeyFingerprintAsHex, rpmPubkeyKeyIDAsHex, at rpmPubkeyArmorWrap, bilang karagdagan sa rpmPubkeyMerge para sa pagsasama ng mga descriptor ng parehong key.
Para sa permanenteng transaction keystore, kasama ang rpmtxnImportPubkey, rpmtxnDeletePubkey, at rpmtxnRebuildKeystore. Ang operasyon ng rpmSign ay kinokontrol gamit ang mga bagong flag : RPMSIGN_FLAG_RESIGN, RPMSIGN_FLAG_RPMV4, at RPMSIGN_FLAG_RPMV6. Idinagdag din ang rpmteVfyLevel at rpmteSetVfyLevel, kasama ang kanilang mga katumbas na te.VfyLevel at te.SetVfyLevel sa mga Python binding.
Para sa maraming lagda, lilitaw ang mga identifier tulad ng RPMTAG_OPENPGP, RPMSIGTAG_OPENPGP (alyas ng nauna) at ang verification flag na RPMVSF_NOOPENPGP. May mga bagong tag na idadagdag : RPMTAG_PAYLOADSIZE, RPMTAG_PAYLOADSIZEALT, RPMTAG_RPMFORMAT, RPMTAG_FILEMIMEINDEX, RPMTAG_MIMEDICT, RPMTAG_FILEMIMES, RPMTAG_SOURCENEVR, RPMTAG_PAYLOADSHA512, RPMTAG_PAYLOADSHA512ALT, RPMTAG_PAYLOADSHA3_256, RPMTAG_PAYLOADSHA3_256ALT, RPMTAG_SHA3_256HEADER.
May mga tag na pinalitan ng pangalan: Ang RPMTAG_PAYLOADDIGEST ay nagiging RPMTAG_PAYLOADSHA256, ang RPMTAG_PAYLOADDIGESTALT ay magiging RPMTAG_PAYLOADSHA256ALT, at ang RPMTAG_PAYLOADDIGESTALGO ay minarkahan bilang hindi na ginagamit sa ilalim ng RPMTAG_PAYLOADSHA256ALGO. Idinaragdag ang mga SHA-3 identifier : RPM_HASH_SHA3_256 at RPM_HASH_SHA3_512, bilang karagdagan sa mga simbolo na nauugnay sa MIME bawat file sa mga v6 package, tulad ng rpmfilesFMime at rpmfiFMime, at ang RPMFI_NOFILEMIME flag.
Sa kapaligirang OpenPGP, naidagdag ang mga identifier na sumusunod sa RFC 9580, kasama ang pgpDigParamsSalt function para sa pagkuha ng pre-salt ng mga v6 signature. Para sa mga digest sets, naidagdag ang rpmDigestBundleUpdateID (ina-update ang mga indibidwal na identifier). Kabilang sa iba pang mga bagong tampok ang: ang rpmtsAddInstallElement ay nagbabalik ng 3 para sa mga hindi sinusuportahang format, at ang fdSize ngayon ay nag-uulat ng mga error para sa mga hindi regular na uri ng file.
Mejoras internas
Ang RPM code ay inililipat sa C++20 (maliban sa mga Python plugin at binding). Ang mga source file ay pinapalitan ng pangalan sa .cc at .hh , ang mga dynamic na istruktura ay inililipat sa STL, at ang pagbibilang ng sanggunian ay pinapalakas gamit ang mga atomic operation. Bukod pa rito, ang test suite ay pinalalawak at ang paggawa ng pagsubok ay pinapasimple.
Isang tunay na keychain abstraction at isang experimental backend batay sa openpgp.cert.d ang ipinakilala. Ang target na `build make site` ay idinagdag upang i-render ang lokal na dokumentasyon, at ang test image ay iniakma sa toolbox. Pinapayagan na ngayon ang mga underscore sa mga pangalan ng RPMTAG, at naayos na ang mga regression, tulad ng nakalaan na laki ng lagda at ang mekanismo ng mga alternatibo na nakakasagabal sa mga lagda.
Naayos na ang mga pagbasa ng keyring nang walang transaction locking, pati na rin ang race condition sa rpmioMkpath, recursion depth sa mga mensahe ng error sa macro, at isang senaryo kung saan ang mga walang laman na field sa passwd o group ay naging sanhi ng pagbalewala sa mga entry. Magagamit na muli ang mga internal macro bago mag-load ng mga file , ang fdSize failure sa rpmSign ay nahawakan nang tama, ang mga pseudo-tag sa --querytags ay nalinis na, at ang installation prefix ay iginagalang sa mga legacy script ng find-provides at find-requires.
Iba pang mga panloob na pagpapabuti
Nalutas na rin ang mga leak ng reference sa Python na may kaugnayan sa mga file, na-stabilize ang dependency storage upang maiwasan ang non-determinism, naayos na ang chroot escape sa sysusers script gamit ang mga entry na u!, at natugunan na ang regression sa 4.19 sa mga nabigong update return code. Nabigyan na ng babala ang mga macrofile sa rpmrc tungkol sa , muling ginawa ang transaction lock matapos maalis ang `--rebuilddb`, `provides gpg(keyid)` mula sa `gpg-pubkey`, at nalinis na ang mga simbolong hindi sinasadyang tumagas sa ABI.
Inalis na ang mga hindi portable na paggamit ng Signal, na-optimize na ang rpmlog blocking, at sinusuportahan na ngayon ng mga Python binding ang module isolation para sa maraming sub-interpreter at inaayos ang mga leak ng resource gamit ang ASAN testing. Pinahuhusay ng mga pagpapahusay na ito ang katatagan, kadalian ng pagdadala, at pagpapanatili sa kabuuan.
Mga kinakailangan para sa pag-compile ng RPM
Kinakailangan na ngayon ang isang C++20 compiler bilang karagdagan sa C99; hindi na kailangan ang suporta sa C++20 module. Ang pagbuo gamit ang Sequoia ay nangangailangan ng rpm-sequoia 1.9.0 o mas mataas pa (at ito ang default), Python 3.10 o mas mataas pa para sa mga binding, at ang scdoc generator para sa mga man pages.
Hindi na kasama ang dokumentasyon ng pre-built API sa mga release tarball; opsyonal ang pagbuo nito gamit ang Doxygen. Available ang mga pre-built API na partikular sa bersyon sa FTP server ng proyekto.
RPM 6.0 Compatibility at Format Keynotes
Ang format ng v6 package ay nagpapakilala ng 64-bit na laki ng file at mga kaugnay na limitasyon, modernisasyon ng cryptographic sa pamamagitan ng pag-alis ng MD5 at SHA1, SHA3-256 hash sa header, at SHA512 at SHA3-256 digests sa payload. Ang impormasyon ng MIME ay idinaragdag sa bawat file , at mayroong malawak na suporta sa RPM simula sa bersyon 4.14 (na may ilang limitasyon). Ang external dependency generator mode ay hindi na sinusuportahan sa v6, at ang mga legacy rpmlib dependencies bago ang bersyon 4.6 ay inalis upang mabawasan ang noise.
Maaaring i-query ang mga v6 package gamit ang mga RPM mula bersyon 4.6 pataas, i-decompress gamit ang 4.12, at i-verify at i-install gamit ang 4.14 o mas bago, napapailalim sa mga kilalang limitasyon. Ang mga v4 package ay nananatiling ganap na sinusuportahan , at ang mga nabuo ng 6.0 ay magkapareho sa mga nasa 4.x branch; gayunpaman, sa ilalim ng default na configuration, ang mga package na binuo gamit ang mga RPM na mas maaga sa 4.14 ay hindi beripikado dahil gumagamit ang mga ito ng mga mahihinang digest. Maaari mong baguhin ang `%_pkgverify_level` sa `signature` upang balewalain ang mga digest na ito, o ibalik ang gawi ng 4.x sa pamamagitan ng pagtatakda ng `%_pkgverify_flags` sa 0 kung kailangan mong i-verify ang mga mahihinang digest.
Ang v3 installation ay inalis, bagama't maaari itong i-query at i-extract gamit ang rpm2cpio. Bilang default, ang RPM ay bumubuo ng mga v6 package ; maaari itong ibalik sa pamamagitan ng pagtatakda ng %_rpmformat sa 4. Sa mga package na binuo gamit ang RPM 6.0 o mas mataas, ang pamilya ng Lua posix.fork ay hindi pinagana, habang sa mga package na binuo gamit ang 4.20 o mas maaga ay patuloy itong gumagana.
Iba pang mga konsiderasyon: Ang configuration ng signing key ay tinukoy na ngayon gamit ang %_openpgp_sign_id (backward compatibility sa %_gpg_name), ang mga low-level signing macro ay parametric na ngayon, at ang mga custom override ng %__gpg_sign_cmd ay hindi na gumagana nang gaya ng dati. Ang %_passwd_path at %_group_path ay sinusuportahan na ngayon bilang mga colon-separated list para sa paggamit ng maraming NSS source, at ang mga –pkgid at –hdrid query switch ay inalis na.
RPM 6.0 at Fedora 43: Saklaw, Mga Benepisyo, at Pagsubok
Ang pag-upgrade sa RPM 6.0 sa Fedora 43 ay naglalayong palakasin ang seguridad at bigyang-daan ang v6 format, ngunit hindi pa ginagamit ang bagong format bilang default. Ang Fedora 43 ay patuloy na bubuo ng v4 bilang default , at ang mahigpit na pagpapatupad ng pag-verify ng lagda ay tutugunan bilang isang pagbabago sa sistema sa susunod na paglabas.
Mga pangunahing benepisyo para sa Fedora: Ang mga OpenPGP key ay palaging nakikilala na ngayon sa pamamagitan ng fingerprint o full ID, maaaring i-update gamit ang rpmkeys –import, sinusuportahan ang maraming lagda bawat pakete, lokal na self-signing sa mga build, at ang paggamit ng Sequoia-sq bilang alternatibo sa GnuPG. Pinapadali rin nito ang pagsubok sa v6 format sa loob ng ecosystem nang hindi pinipilit ang pandaigdigang pag-aampon nito.
Ang mga sumusunod ay wala sa saklaw: ang pangkalahatang paglipat ng Fedora sa v6 na format at ang pagbabago ng default na verification mode. Ang mga responsable sa pagbabago ay humahawak sa mga RPM override at tumutulong sa mga hindi pagkakatugma, habang ang iba pang mga developer ay responsable sa pagsubok, pag-uulat ng mga problema, at pag-aangkop ng mga tool ng third-party kung kinakailangan.
Epekto ng update at compatibility: Ang mga script at tool ng third-party ay maaaring mangailangan ng mga pagsasaayos dahil sa bagong format ng key address at mga kaugnay na pagbabago sa output ng signature. Para sa maagang pagsubok, ipinapayong i-validate ang: pag-update ng mga imported na key, pamamahala ng keychain gamit ang rpmkeys, at compatibility ng v6 format sa external software (sa pamamagitan ng pagtatakda ng %_rpmformat sa 6).
RPM 6.0 Karanasan ng Gumagamit sa Fedora
Karanasan ng Gumagamit: Ang lagda at output na may kaugnayan sa key ay inistandardisa sa parehong malaki at maliit na titik, at ang mga key ay ipinapakita sa pamamagitan ng fingerprint o buong ID, na iniiwan ang luma at madaling magkabanggaang maikling ID. Ang rpmkeys ay itinatag bilang opisyal na tool sa keyring; ang mga lumang pamamaraan tulad ng manu-manong pagmamanipula ng mga pseudo-package ng gpg-pubkey ay hindi na ginagamit at dapat ilipat sa rpmkeys o sa mga bagong API.
Mga Dependency: Ang soname ay nananatiling hindi nagbabago, kaya hindi kinakailangan ang muling pagbuo ng dependency; walang mga dependency sa iba pang mga pagbabago sa Fedora. Ang RPM ay binuo tulad ng C++, kaya nagdaragdag ito ng runtime dependency sa libstdc++. Ang pag-sign gamit ang Sequoia ay nangangailangan ng sequoia-sq 1.0 o mas mataas bilang isang opsyonal na dependency at nakakaapekto lamang sa pag-sign ng package.
Plano para sa mga hindi inaasahang pangyayari: ibalik sa RPM 4.20 kung kinakailangan, na may deadline sa beta freeze, nang hindi hinaharangan ang paglabas. Magpapatuloy ang paghahatid kahit na ang v6 format ay hindi pa ang default sa distribusyon.
RPM 6.0 Release Notes at Background Announcement
Ang nakaraang kandidato sa paglabas ay nagsama ng mga pag-aayos ng bug at mga pag-update sa man page at na-promote sa final. Ang anunsyo, na nilagdaan ng RPM team, ay nagbibigay-diin na ang pagsisikap patungo sa milestone na ito ay isinasagawa simula nang i-reboot ang rpm.org noong bandang 2007, na may mga milestone kabilang ang 64-bit na laki ng file, mga pluggable dependency generator, mga transaction plugin, mga rich dependencies, mga file trigger, mga pagpapabuti sa debuginfo, mga bagong database backend, pagsasama ng Lua at mga macro expression, mga dynamic build-requirement, pagbuo ng spec, suporta sa user at group, at mga declarative build system.
Mahigit 300 katao ang nag-ambag ng code mula sa iba't ibang distribusyon at organisasyon. Ang kasaysayan ng proyekto at ng komunidad nito ay nagpapaliwanag sa katatagan at saklaw na minana at pinalalawak ng RPM 6.0.
Ang larawang ipininta ng RPM 6.0 ay ang isang pinatibay na package manager para sa susunod na dekada: mas mahusay na cryptography, isang format na handa para sa malalaking volume, mas makapangyarihang mga tool at napapanahong dokumentasyon , na may malinaw na landas sa pagiging tugma upang ang mga administrador, packager, at ecosystem ay magamit ang mga bagong tampok nang walang mga sorpresa.
