ຄັງເກັບຊອບແວ Fedora

For stable releases, fedora represents the frozen release state. It is a part of the frozen tree that is created by Release Engineering when a release is approved at a Go/No-Go Meeting. The package set it includes never changes after that time. It represents the stable state of a stable release in conjunction with updates repository.

The stable release fedora repositories for the various primary architectures can be found in the /fedora/linux/releases/XX/Everything directory on the mirrors (where XX is the release), and can also be queried from MirrorManager. For example, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-44&arch=x86_64 will return mirrors for the x86_64 fedora repository for release 44.

ໃນລຸ້ນແຕກແໜງ (Branched) - ເຊິ່ງເປັນສະຖານະລຸ້ນທີ່ຢູ່ລະຫວ່າງການແຍກຕົວອອກຈາກ Rawhide ແລະ ກ່ອນຈະເປັນລຸ້ນສະຖຽນ, ເບິ່ງລາຍລະອຽດເພີ່ມເຕີມໄດ້ທີ່ Branched - ຄັງເກັບຊອບແວ fedora ພຽງຢ່າງດຽວຈະເປັນຕົວແທນຂອງສະຖານະສະຖຽນຂອງລຸ້ນນັ້ນ. ຄັງເກັບຊອບແວ updates ສຳລັບລຸ້ນ Branched ຈະຍັງບໍ່ຖືກໃຊ້ງານຈົນກວ່າພວກມັນຈະກາຍເປັນລຸ້ນສະຖຽນ. ກ່ອນທີ່ຈະມີການ ເປີດໃຊ້ງານ updates-testing, ແພັກເກດທີ່ຖືກສ້າງຂຶ້ນສຳລັບລຸ້ນ Branched ຈະຖືກສົ່ງໄປທີ່ຄັງເກັບຊອບແວນີ້ໂດຍກົງ. ຫຼັງຈາກ ຈຸດເປີດໃຊ້ງານ Bodhi (Bodhi enabling point), ແພັກເກດທີ່ຜ່ານເກນ ນະໂຍບາຍການອັບເດດ ຈະຖືກຍ້າຍຈາກຄັງເກັບຊອບແວ updates-testing ມາທີ່ຄັງເກັບຊອບແວນີ້.

The Branched fedora repositories for the various primary architectures can be found in the /fedora/linux/development/XX directory on the mirrors (where XX is the release), and can also be queried from MirrorManager. For example, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-45&arch=x86_64 will return mirrors for the x86_64 fedora repository for release 45.

The updates-testing repository exists for Branched releases after the Bodhi enabling point, and for stable releases. It is represented for DNF in the fedora-updates-testing.repo file in the repository path. For both, it is a 'staging' location where new package builds are tested before being marked as 'stable' (and therefore moving to the fedora repository or the updates repository, respectively).

ແພັກເກດເຫຼົ່ານີ້ບາງຄັ້ງຖືກເອີ້ນວ່າ ຕົວເລືອກການອັບເດດ (update candidates), ແລະ ຈະຖືກກວດສອບຜ່ານ ເຄື່ອງມືໃຫ້ຄຳຄິດເຫັນການອັບເດດ Bodhi, ຕາມ ແນວທາງການໃຫ້ຄຳຄິດເຫັນການອັບເດດ.

ນະໂຍບາຍການອັບເດດ ກຳນົດກົດເກນໃນການປ່ຽນສະຖານະ ຕົວເລືອກການອັບເດດໃຫ້ເປັນ ສະຖຽນ (stable). ໜ້າ QA updates-testing ໃຫ້ຂໍ້ມູນສຳລັບຜູ້ທົດສອບໃນການໃຊ້ງານຄັງເກັບຊອບແວນີ້. ສ່ວນ ຄູ່ມືການອັບເດດແພັກເກດ ໃຫ້ຂໍ້ມູນສຳລັບຜູ້ສ້າງແພັກເກດໃນການສົ່ງແພັກເກດໄປທີ່ updates-testing ແລະ ໄປທີ່ stable.

The updates-testing repository is enabled by default for Branched releases, but disabled by default for stable releases. The switchover is made around the time of the Final Freeze for each release. Testers moving from Branched to stable may encounter errors running updates around this time, caused by dependency mismatches between packages already installed from the now-disabled updates-testing repository. Running dnf distro-sync or re-enabling the updates-testing repository will both usually alleviate the issue; it is up to the individual user whether they want to continue using the updates-testing repository after the stable release or not.

The updates-testing repositories for both Branched and stable releases can be found in the /fedora/linux/updates/testing/XX directory on the mirrors (where XX is the release), and can also be queried from MirrorManager. For example, https://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f44&arch=x86_64 will return mirrors for the x86_64 updates-testing repository for release 44.

ໃນ Rawhide - ເຊິ່ງແມ່ນຄັງເກັບຊອບແວແບບ rolling release ຂອງ Fedora, ບ່ອນທີ່ລຸ້ນຕ່າງໆຈະ ແຕກແໜງ (Branched) ອອກມາກ່ອນຈະກາຍເປັນລຸ້ນສະຖຽນ - rawhide ແມ່ນຄັງເກັບຊອບແວພຽງອັນດຽວ. ທຸກໆແພັກເກດທີ່ສ້າງຂຶ້ນຈະຖືກສົ່ງໄປທີ່ນັ້ນ. ມັນຖືກກຳນົດຄ່າສຳລັບ DNF ໃນໄຟລ໌ fedora-rawhide.repo ຢູ່ໃນເສັ້ນທາງຂອງຄັງເກັບຊອບແວ. ສຳລັບລະບົບໃດທີ່ໃຊ້ Rawhide ຢູ່, ຄວນຈະເປີດໃຊ້ງານມັນໄວ້. ແຕ່ສຳລັບລະບົບອື່ນໆ, ບໍ່ຄວນເປີດໃຊ້ງານ.

The rawhide repositories for the various primary architectures can be found in the directory on the mirrors, and can also be queried from MirrorManager. For example, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide&arch=x86_64 will return mirrors for the x86_64 fedora repository for Rawhide.

ມັນບໍ່ແມ່ນເລື່ອງແປກທີ່ຈະເຫັນການອ້າງອີງເຖິງ 'ຄັງເກັບຊອບແວ stable', ແຕ່ຄຳເວົ້ານີ້ບໍ່ຖືກຕ້ອງປານໃດ. stable ເປັນຄືກັບສະຖານະທີ່ຖືວ່າເປັນຢູ່ສຳລັບທັງລຸ້ນ Branched ຫຼັງຈາກ ເປີດໃຊ້ງານ Bodhi ແລະ ສຳລັບລຸ້ນສະຖຽນ. ມັນປະກອບດ້ວຍແພັກເກດທີ່ເປັນສ່ວນໜຶ່ງຂອງ Rawhide ໃນຕອນທີ່ແຕກແໜງອອກມາ, ແພັກເກດທີ່ຖືກສົ່ງໂດຍກົງໄປທີ່ຄັງເກັບຊອບແວ fedora ຂອງລຸ້ນ Branched ໃນຊ່ວງລະຫວ່າງຈຸດແຕກແໜງ ແລະ ຈຸດເປີດໃຊ້ງານ Bodhi, ແລະ ແພັກເກດທີ່ຜ່ານເກນ ນະໂຍບາຍການອັບເດດ ແລະ ຖືກຍ້າຍມາຈາກ updates-testing ຫຼັງຈາກ ຈຸດເປີດໃຊ້ງານ Bodhi.

ສຳລັບລຸ້ນ Branched, ສະຖານະ stable ແມ່ນສະແດງອອກໂດຍເນື້ອຫາປັດຈຸບັນຂອງຄັງເກັບຊອບແວ fedora ພຽງຢ່າງດຽວ (ແລະ ອາດຈະລວມເຖິງຄັງເກັບຊອບແວ bleed ໃນບາງກໍລະນີໜ້ອຍໆ).

ສຳລັບລຸ້ນສະຖຽນ, ສະຖານະ stable ແມ່ນສະແດງອອກໂດຍເນື້ອຫາຂອງຄັງເກັບຊອບແວ fedora ລວມກັບເນື້ອຫາຂອງຄັງເກັບຊອບແວ updates.

stable ຍັງເປັນສະຖານະທີ່ແພັກເກດຖືກພິຈາລະນາວ່າຢູ່ (ຫຼື ເປັນຄຸນລັກສະນະທີ່ມັນມີ) ເມື່ອມັນໄດ້ຖືກ ດັນໄປຫາສະຖານະສະຖຽນ (pushed stable) ຫຼື ໝາຍໄວ້ວ່າສະຖຽນ (tagged stable) ແລະ ມີຢູ່, ຫຼື ກຳລັງຈະມີຢູ່ໃນຄັງເກັບຊອບແວ stable ຂອງລຸ້ນໃດໜຶ່ງ - ບໍ່ວ່າຄັງເກັບຊອບແວນັ້ນຈະມີຊື່ແທ້ໆວ່າແນວໃດກໍຕາມ (ເບິ່ງດ້ານເທິງ).

The bleed repository exists for a single purpose: during Milestone freezes, it includes packages that have been granted 'freeze exceptions' via the Blocker Bug Process or Freeze Exception bug process, and which are desired to be included in the next test compose or release candidate build, but have not yet reached stable state and therefore moved to the fedora repository. That is, it includes packages explicitly required in TC/RC compose requests.

The bleed repository can be found here, but again, is not usually of interest to the vast majority of Fedora users. The packages it includes are always also available from the build system, Koji, and usually from the updates-testing repository.

ຄັງເກັບຊອບແວ latest ບັນຈຸແພັກເກດສຳລັບ 'ປ້າຍກຳກັບ' (tags) ການສ້າງຕ່າງໆ ເມື່ອພວກມັນຖືກສົ່ງມາຮອດລະບົບ Koji. ພວກມັນຍັງບໍ່ທັນ ໄດ້ຜ່ານຂະບວນການ mashed (ຂະບວນການທີ່ຈັດການ ກ່ຽວກັບ multilib ເປັນຫຼັກ), ແລະ ການໃຊ້ງານພວກມັນອາດຈະກໍ່ໃຫ້ເກີດບັນຫາຕ່າງໆ ພ້ອມທັງ ເຮັດໃຫ້ເຊີບເວີພັດທະນາຂອງ Fedora ເຮັດວຽກໜັກເກີນໄປ. ໂດຍທົ່ວໄປແລ້ວ ການເລືອກເອົາ (cherry-pick) ແພັກເກດໃໝ່ຈາກ Koji ຫຼື Bodhi ຜ່ານທາງເວັບ ຫຼື ເຄື່ອງມືຄຳສັ່ງ (command line) ແມ່ນທາງເລືອກທີ່ດີກວ່າ.

ຕາມທີ່ໄດ້ອະທິບາຍໄວ້ຂ້າງເທິງ, ການອັບເດດສຳລັບທັງລຸ້ນທົດລອງ Branched ແລະ ລຸ້ນປ່ອຍຕົວຈິງ ສະຖຽນ (stable) ຈະຕ້ອງຜ່ານຂະບວນການ updates-testing ກ່ອນທີ່ຈະຖືກຍ້າຍໄປທີ່ຄັງເກັບຊອບແວ ສະຖຽນ. ກ່ອນການປ່ອຍຕົວຈິງ, ພວກມັນຈະຖືກຈັດໄວ້ໃນຄັງເກັບຊອບແວ fedora. ແຕ່ຫຼັງການປ່ອຍຕົວຈິງ, ພວກມັນຈະຖືກຈັດໄວ້ໃນ updates.

The reason for the difference is that we want to have a record of the exact 'state' of a given Fedora stable release. That is, at the time a Fedora release is declared to be done at a Go/No-Go Meeting, we consider the state of the release at that time to be the canonical definition of that release, and we want to preserve a record of that state. For a stable release, the tree containing the fedora repository is that record, and the fedora repository it includes is the canonical record of the precise frozen package set that formed the main part of that stable release.

Since we want to maintain this frozen state for the fedora repository, we cannot place updates directly into it. The necessity for the updates repository therefore becomes obvious - we need a place to put updates to stable releases that is outside the frozen state of the release.

ກ່ອນທີ່ຈະມີການປ່ອຍລຸ້ນສະຖຽນ, ກົນໄກນີ້ຍັງບໍ່ຈຳເປັນ. ກ່ອນທີ່ລຸ້ນຈະຖືກປະກາດວ່າສຳເລັດ, ມັນຍັງບໍ່ມີສະຖານະ 'ຢຸດການປ່ຽນແປງ' ຂອງລຸ້ນນັ້ນ: ເວົ້າງ່າຍໆຄື ຂະບວນການພັດທະນາ Branched ທັງໝົດແມ່ນ 'ການເຮັດວຽກເພື່ອມຸ່ງໄປສູ່' ສິ່ງທີ່ຈະກາຍມາເປັນສະຖານະ 'ຢຸດການປ່ຽນແປງ' ຂອງລຸ້ນ, ດັ່ງນັ້ນ ແພັກເກດຕ່າງໆຂອງລຸ້ນ Branched ຈຶ່ງຖືກສົ່ງໄປທີ່ຄັງເກັບຊອບແວ fedora ໂດຍກົງ.

ເຖິງແມ່ນວ່າທັງລຸ້ນພັດທະນາ Branched ແລະ ລຸ້ນສະຖຽນ ຈະໃຊ້ຄັງເກັບຊອບແວ updates-testing ຮ່ວມກັບລະບົບໃຫ້ຄຳຄິດເຫັນ Bodhi ເພື່ອພັກແພັກເກດກ່ອນທີ່ຈະໄປຮອດສະຖານະ ສະຖຽນ, ແຕ່ມັນຈະຖືກເປີດໃຊ້ງານໄວ້ເປັນຄ່າເລີ່ມຕົ້ນໃນລຸ້ນ Branched ເທົ່ານັ້ນ, ແຕ່ບໍ່ໄດ້ເປີດໃນລຸ້ນສະຖຽນ.

ເຫດຜົນແມ່ນຍ້ອນວ່າ ຈຸດປະສົງຂອງລະບົບ updates-testing ໃນແຕ່ລະກໍລະນີນັ້ນແຕກຕ່າງກັນເລັກນ້ອຍ. ສຳລັບລຸ້ນສະຖຽນ, ເປົ້າໝາຍຂອງລະບົບແມ່ນເພື່ອປ້ອງກັນບໍ່ໃຫ້ການອັບເດດທີ່ມີບັນຫາໄປຮອດ ຜູ້ໃຊ້ Fedora ທົ່ວໄປ. ໃນກໍລະນີສ່ວນໃຫຍ່, ລະບົບ Fedora ຄວນຈະປິດຄັງເກັບຊອບແວ updates-testing ໄວ້. ຈາກນັ້ນ ຜູ້ທົດສອບ QA ບາງຄົນຈະເປີດມັນໃນລະບົບທົດສອບເພື່ອລອງໃຊ້ການອັບເດດ ແລະ ໃຫ້ຄຳຄິດເຫັນ. ຜູ້ທົດສອບຈະເຮັດໜ້າທີ່ກວດສອບໃຫ້ແນ່ໃຈວ່າການອັບເດດນັ້ນໃຊ້ງານໄດ້ດີ ກ່ອນທີ່ຈະປ່ອຍໃຫ້ຜູ້ໃຊ້ທົ່ວໄປ.

ເມື່ອເວົ້າເຖິງລຸ້ນທົດລອງ Branched, ພວກເຮົາຄາດຫວັງວ່າທຸກຄົນທີ່ຕິດຕັ້ງມັນແມ່ນຕ້ອງການທີ່ຈະ ຊ່ວຍທົດສອບ: ພວກເຮົາຖືວ່າໃຜກໍຕາມທີ່ໃຊ້ລຸ້ນ Branched ແມ່ນຜູ້ທົດສອບ. ໜ້າທີ່ຂອງ updates-testing ໃນກໍລະນີນີ້ຈຶ່ງຕ່າງອອກໄປ. ມັນບໍ່ມີ 'ຜູ້ໃຊ້ທົ່ວໄປ' ໃນກຸ່ມຜູ້ໃຊ້ Branched ທີ່ຈະປິດ updates-testing ໄວ້ເພື່ອລໍຖ້າໃຫ້ກຸ່ມຜູ້ທົດສອບກວດສອບກ່ອນ. ແຕ່ໃນລຸ້ນ Branched, updates-testing ຈະເຮັດໜ້າທີ່ສຳຄັນອື່ນໆແທນ.

ຈຸດປະສົງຫຼັກແມ່ນເພື່ອແຍກ ການສ້າງໄຟລ໌ອິມເມຈ (image builds) ອອກຈາກການປ່ຽນແປງທີ່ອາດ ກໍ່ໃຫ້ເກີດບັນຫາ. ໄຟລ໌ອິມເມຈຂອງ Branched - ທັງ nightly images, ແລະ ຊຸດ Alpha, Beta, GA (Final) ລວມເຖິງ ຊຸດທົດສອບ ແລະ ຊຸດລໍຖ້າການປ່ອຍ - ແມ່ນຖືກສ້າງຂຶ້ນຈາກແພັກເກດ ສະຖຽນ, ເຊິ່ງກໍຄືແພັກເກດທີ່ຢູ່ໃນຄັງເກັບຊອບແວ fedora ເທົ່ານັ້ນ, ບໍ່ແມ່ນຈາກ updates-testing. ໃນແງ່ນີ້, updates-testing ບໍ່ໄດ້ປ້ອງກັນກຸ່ມຜູ້ໃຊ້, ແຕ່ປ້ອງກັນ 'ຊຸດການສ້າງ' (builds) ຈາກການປ່ຽນແປງທີ່ອາດເຮັດໃຫ້ລະບົບບໍ່ໝັ້ນຄົງ. ໂດຍສະເພາະ ໃນຊ່ວງທີ່ພວກເຮົາສ້າງລຸ້ນ Alpha, Beta ຫຼື GA, ພວກເຮົາຈຳເປັນຕ້ອງຫຼຸດປະລິມານການປ່ຽນແປງ ຂອງຊຸດແພັກເກດໃນແຕ່ລະຊຸດການສ້າງ ເພື່ອໃຫ້ໄດ້ໄຟລ໌ອິມເມຈທີ່ມີຄຸນນະພາບສູງ. ກົນໄກຂອງ updates-testing ຊ່ວຍໃນເລື່ອງນີ້ໄດ້: ໃນຊ່ວງ ການຢຸດປ່ຽນແປງລຸ້ນ, ແພັກເກດໃໝ່ສາມາດຖືກສົ່ງໄປທີ່ updates-testing ໄດ້, ແຕ່ຈະບໍ່ສາມາດຍ້າຍຈາກບ່ອນນັ້ນໄປຫາ ສະຖຽນ (fedora) ໄດ້ ຖ້າບໍ່ມີກໍລະນີພິເສດ. ດ້ວຍວິທີນີ້, ພວກເຮົາຈຶ່ງສາມາດເຮັດວຽກກັບ ໄຟລ໌ອິມເມຈທີ່ຈະປ່ອຍໄດ້ ໂດຍທີ່ບໍ່ໄດ້ປິດກັ້ນຜູ້ສ້າງແພັກເກດໃນການສົ່ງແພັກເກດໃໝ່ໆອອກມາ.

ສຳລັບໜ້າທີ່ນີ້ ແລະ ໜ້າທີ່ອື່ນໆທີ່ສຳຄັນໜ້ອຍກວ່າ, ພວກເຮົາຕ້ອງການຄຳຄິດເຫັນໃຫ້ຫຼາຍທີ່ສຸດເທົ່າທີ່ຈະຫຼາຍໄດ້, ດັ່ງນັ້ນ ມັນຈຶ່ງສົມເຫດສົມຜົນທີ່ຈະໃຫ້ຜູ້ທົດສອບລຸ້ນທົດລອງທຸກຄົນເປີດໃຊ້ງານ updates-testing ໄວ້ເປັນຄ່າເລີ່ມຕົ້ນ, ແລະ ສະໜັບສະໜູນໃຫ້ພວກເຂົາໃຫ້ຄຳຄິດເຫັນຜ່ານ Bodhi.

See a typing error, something missing or out of date, or anything else which can be improved? Edit this document at https://forge.fedoraproject.org/docs/quick-docs.