หากคุณใช้ Arch Linux หรือระบบปฏิบัติการที่พัฒนาต่อยอดจาก Arch Linux (เช่น EndeavourOS, Manjaro, Artix เป็นต้น) ไม่ช้าก็เร็วคุณจะต้องเจอกับปัญหานี้ แหล่งเก็บข้อมูล AUR และตัวช่วยสร้างไฟล์ชื่อดังอย่าง yay และ paruทุกคนพูดถึงมัน มีการแนะนำในฟอรัม และปรากฏอยู่ในคู่มือเกือบทุกเล่ม แต่เมื่อคุณพยายามตัดสินใจว่าจะใช้อันไหน ความแตกต่างก็ไม่ได้ชัดเจนเสมอไป
ในบรรทัดต่อไปนี้ เราจะค่อยๆ วิเคราะห์ว่าแต่ละอย่างมีอะไรบ้าง ความคิดเห็นที่แท้จริงของชุมชนเป็นอย่างไร และมีเรื่องเข้าใจผิดอะไรเกี่ยวกับแต่ละอย่างบ้าง “เย่ตายแล้ว” หรือ “ปารุเร็วกว่ามาก”และในกรณีใดบ้างที่ควรเปลี่ยนจากผู้ช่วยคนหนึ่งไปอีกคนหนึ่ง แนวคิดก็คือ ในตอนท้าย คุณจะมีเหตุผลที่หนักแน่นในการเลือกผู้ช่วยโดยไม่ต้องคิดมากเกินไป
yay และ paru คืออะไร และทำไมทุกคนถึงใช้คำเหล่านี้?
โดยทั่วไปแล้ว ทั้ง yay และ paru ต่างก็เป็น ตัวช่วย AUR ที่ทำงานอัตโนมัติในการค้นหา รวบรวม และติดตั้งแพ็กเกจ จาก AUR นอกเหนือจากการจัดการแพ็กเกจจากที่เก็บอย่างเป็นทางการโดยใช้ pacman เบื้องหลัง นั่นคือ แทนที่จะเข้าไปที่เว็บไซต์ AUR ดาวน์โหลดไฟล์ PKGBUILD และเรียกใช้งานด้วยตนเอง makepkg จากนั้นจึงติดตั้งแพ็กเกจ พวกเขาทำทั้งหมดนั้นในคราวเดียว
ในสภาพแวดล้อมของ Arch และเวอร์ชันที่พัฒนาต่อยอดจาก Arch นั้น เป็นเรื่องปกติมากที่จะต้องการเข้าถึง... มีซอฟต์แวร์หลากหลายประเภทให้เลือกใช้ใน AURที่นั่นคุณจะพบแอปพลิเคชันที่ไม่ได้อยู่ในคลังเก็บอย่างเป็นทางการ เวอร์ชัน Git แพตช์ทดลอง หรือโปรแกรมที่ยังไม่มีใครจัดทำเป็นแพ็กเกจอย่างเป็นทางการ ตัวอย่างเช่น คู่มือสำหรับ การติดตั้ง Visual Studio Code บน Archเพื่อให้จัดการสิ่งต่างๆ เหล่านั้นได้ง่ายขึ้น คนส่วนใหญ่จึงมักใช้ผู้ช่วย และนั่นคือที่มาของแอป yay และ paru ซึ่งเป็นสองตัวเลือกยอดนิยมที่สุด
Yay เป็นหนึ่งในแบรนด์ชั้นนำมานานหลายปีแล้ว: เป็นที่รู้จักกันดี มีการบันทึกไว้ และมีชุมชนขนาดใหญ่ และมักปรากฏเป็นค่าเริ่มต้นในดิสทริบิวชันต่างๆ เช่น EndeavourOS ในทางกลับกัน Paru เป็นดิสทริบิวชันที่ใหม่กว่า แต่ได้รับความนิยมอย่างมากเนื่องจากมีแนวทางการทำงาน AUR ที่เข้มงวดและปลอดภัยกว่า และเนื่องจากผู้พัฒนาเคยมีส่วนร่วมในการพัฒนา yay ในอดีต
ความแตกต่างทางเทคนิค: Go กับ Rust, การออกแบบและปรัชญา
ประเด็นหนึ่งที่มักถูกหยิบยกขึ้นมาในการอภิปรายทุกครั้งก็คือว่า yay เขียนด้วยภาษา Go และ paru เขียนด้วยภาษา Rustในทางเทคนิคแล้ว เรื่องนี้มีความสำคัญต่อผู้ใช้ปลายทางน้อยกว่าที่บางครั้งมีการกล่าวอ้าง แต่ก็สะท้อนให้เห็นถึงแนวทางการดำเนินงานของแต่ละโครงการได้
Yay ซึ่งพัฒนาด้วยภาษา Go ได้รับแรงบันดาลใจจากผู้ช่วยอัจฉริยะรุ่นเก่าๆ เช่น yaourt, apacman และ pacaurโค้ดของมันอ่านง่ายและต่อยอดได้ค่อนข้างง่ายสำหรับผู้ที่เชี่ยวชาญภาษาโก และหนึ่งในคุณสมบัติเด่นทางประวัติศาสตร์ของมันก็คือจุดนี้เอง กระบวนการรวบรวมข้อมูลนั้นรวดเร็วและไม่ยุ่งยากรากฐานดังกล่าวทำให้โครงการนี้ยังคงอยู่รอดได้แม้จะมีการเปลี่ยนแปลงในทีมพัฒนา
ในทางกลับกัน Paru ถูกพัฒนาขึ้นด้วยภาษา Rust และดึงเอาประสบการณ์จาก yay มาใช้โดยตรง ทั้งในด้านฟังก์ชันการทำงานและการออกแบบส่วนติดต่อผู้ใช้แบบบรรทัดคำสั่ง ด้วยเหตุนี้ การย้ายข้อมูลจาก yay ไปยัง paru นั้นง่ายมากคำสั่งและตัวเลือกหลายอย่างให้ความรู้สึกคล้ายคลึงกันมาก ดังนั้นคุณจึงไม่จำเป็นต้องเรียนรู้ทุกอย่างใหม่ตั้งแต่ต้น
ในแง่ปรัชญา ปารูให้ความสำคัญกับเรื่องนี้มากกว่าเรื่องอื่น การรักษาความปลอดภัยและการตรวจสอบไฟล์ PKGBUILDโดยทั่วไปแล้ว yay มักให้ความสำคัญกับขั้นตอนการทำงานที่รวดเร็วและสะดวกสบายกว่าเป็นอันดับแรก ความแตกต่างนี้เห็นได้ชัดเจนในวิธีการนำเสนอไฟล์ก่อนที่จะสร้างแพ็กเกจ
ความเร็ว: ปารุเร็วกว่าเย่จริงเหรอ?
หนึ่งในประเด็นถกเถียงที่ถูกพูดถึงบ่อยที่สุดในฟอรัมและเครือข่ายสังคมออนไลน์คือ... paru นั้น "เร็วกว่า" yayควรชี้แจงประเด็นนี้ให้ชัดเจน ผู้ใช้หลายรายที่มีฮาร์ดแวร์ทรงพลังและการเชื่อมต่อที่ดี (เช่น ไฟเบอร์ 1 Gbps) รายงานว่า ในทางปฏิบัติแล้ว ความรู้สึกถึงความเร็วระหว่างทั้งสองนั้นคล้ายคลึงกันมากในระบบลักษณะนี้ ปัญหาคอขวดมักอยู่ที่การดาวน์โหลดหรือการคอมไพล์ซอฟต์แวร์เอง ไม่ใช่ตัวช่วยสร้างการดาวน์โหลดหรือคอมไพล์
ถึงกระนั้น บางคนก็เปรียบเทียบทั้งสองแบบบนเครื่องคอมพิวเตอร์ที่มีสเปคต่ำกว่า และอ้างว่า Paru สามารถดำเนินการบางอย่างได้เร็วกว่าเล็กน้อยสิ่งนี้สังเกตได้ชัดเจนเป็นพิเศษเมื่อทำการค้นหา การซิงโครไนซ์ หรือการอัปเดตทั่วโลกที่เกี่ยวข้องกับทั้งที่เก็บข้อมูลอย่างเป็นทางการและ AUR ความแตกต่างมักจะไม่มากนัก แต่ในระบบที่มีทรัพยากรจำกัดหรือดิสก์ช้า คุณอาจเห็นการปรับปรุงเล็กน้อยในบางจุด
อีกด้านหนึ่งของเหรียญก็คือ โดยค่าเริ่มต้น paru จะบังคับให้คุณตรวจสอบไฟล์ PKGBUILD ก่อนทำการคอมไพล์นี่เป็นการเพิ่มขั้นตอนแบบโต้ตอบซึ่งเห็นได้ชัดว่าใช้เวลาของมนุษย์ (ถึงแม้จะเพียงเล็กน้อย) ผู้ใช้บางคนมองว่านี่เป็น "อุปสรรค" ในขณะที่บางคนมองว่าเป็นทางออกที่สมเหตุสมผลเพราะให้ความปลอดภัยและความโปร่งใส
กล่าวโดยสรุป หากคุณมีคอมพิวเตอร์รุ่นใหม่และการเชื่อมต่ออินเทอร์เน็ตที่ดี ความแตกต่างของความเร็วระหว่างเย่และปารุจะน้อยมากการเลือกใช้ Paru อาจคุ้มค่าอย่างแท้จริงในระบบที่มีข้อจำกัดซึ่งทุกวินาทีมีความสำคัญ หรือหากคุณต้องการผู้ช่วยที่ได้รับการปรับแต่งอย่างละเอียดทุกขั้นตอน และคุณสังเกตเห็นข้อได้เปรียบเล็กน้อยนั้น
ไวยากรณ์และประสบการณ์ผู้ใช้: ความรู้สึกขณะพิมพ์
นอกเหนือจากการเปรียบเทียบประสิทธิภาพและการอภิปรายทางเทคนิคแล้ว ผู้ใช้จำนวนมากยังรู้สึก "ดีใจ" ด้วยเหตุผลที่ค่อนข้างธรรมดา: การเขียนนั้นสบายมากบางคนบอกว่าพวกเขา "กดปุ่มทั้งสองพร้อมกัน" เพื่อพิมพ์คำว่า yay เพราะมันสั้น จำง่าย และมีระบบเติมคำอัตโนมัติในเทอร์มินัล
ชื่อปารุไม่ใช่ชื่อที่แย่เสียทีเดียว แต่บางคนก็บอกว่า... ไวยากรณ์ของพวกเขานั้นดู "หยาบ" กว่าเล็กน้อยในสายตาของพวกเขา เมื่อใช้งานเป็นประจำทุกวัน คำสั่งต่างๆ อาจไม่ได้แตกต่างกันมากนัก แต่เป็นเรื่องของระบบความคุ้นเคย และผู้ที่ใช้ yay มาหลายปีจะรู้สึกว่าขั้นตอนการทำงานเป็นธรรมชาติและรวดเร็วกว่า ทั้งในด้านความคิดและการพิมพ์
อย่างไรก็ตาม ผู้ช่วยทั้งสองคนต่างก็ให้ข้อมูล ทางลัด ตัวเลือกแบบโต้ตอบ และแฟล็กที่คล้ายคลึงกันมากตัวอย่างเช่น ฟีเจอร์ต่างๆ เช่น การแสดงเมนูรวมของการอัปเดตจาก repository และ AUR พร้อมรายละเอียดเวอร์ชัน มีให้ใช้งานในทั้งสองแพลตฟอร์ม ใน yay มีตัวเลือกหนึ่ง --combinedupgradeซึ่งจะแสดงรายการที่ใช้รหัสสีเพื่อระบุว่าอะไรจะได้รับการอัปเดต และจากเวอร์ชันใดไปเป็นเวอร์ชันใด ใน Paru สามารถทำสิ่งที่คล้ายกันได้ผ่านตัวเลือกนี้ --upgrademenuซึ่งมีรายการอัปเดตโดยละเอียดให้เลือกชม
รายละเอียดที่น่าสนใจอย่างหนึ่งที่ปรากฏในกระทู้บางกระทู้ก็คือ ผู้ใช้บางรายถึงกับสร้างชื่อเรียกแทนขึ้นมาด้วยซ้ำ yaya เย้เพราะพวกเขาพบว่าการเรียกใช้งานด้วยวิธีนั้นสะดวกและสนุกกว่า นี่แสดงให้เห็นอย่างชัดเจนว่าหลักการออกแบบตามหลักสรีรศาสตร์และนิสัยมีบทบาทสำคัญอย่างยิ่งในการเลือกผู้ช่วยส่วนตัว
แต่ละแพ็กเกจที่คอมไพล์แล้วจะถูกจัดเก็บไว้ที่ใด?
อีกแง่มุมที่น่าสนใจซึ่งมักถูกมองข้ามไปคือการบริหารจัดการ แพ็คเกจสำเร็จรูป (ไฟล์ .pkg.tar.zst)ในที่นี้ yay และ paru มีพฤติกรรมที่แตกต่างกันเล็กน้อย และนั่นส่งผลต่อวิธีการผสานรวมเข้ากับเส้นทาง Arch ทั่วไป
ค่าเริ่มต้น, makepkg จะจัดเก็บแพ็กเกจที่สร้างเสร็จแล้วไว้ในไดเร็กทอรี buildเส้นทางดังกล่าวสามารถปรับเปลี่ยนได้โดยใช้ตัวแปร PKGDEST en /etc/makepkg.confดังนั้นคุณจึงสามารถส่งพวกมันไปที่ ตัวอย่างเช่น /var/cache/pacman/pkg/ เพื่อรวมศูนย์ไฟล์ไบนารีที่บรรจุแล้ว
ในกรณีของ paru นั้น จะเคารพพฤติกรรมปกติของ makepkg: แพ็กเกจเหล่านั้นจะถูกจัดเก็บไว้ในไดเร็กทอรีการคอมไพล์ที่เกี่ยวข้องกับ paruโดยปกติแล้วจะเป็นอะไรประมาณนี้ ~/.cache/paru/clone/$pkgname/หากคุณต้องการแก้ไขเส้นทางนั้นทั่วทั้งระบบ คุณสามารถใช้ตัวเลือกดังกล่าวได้ BuildDir en /etc/paru.confส่งต่อไฟล์รวบรวมข้อมูลไปยังเว็บไซต์อื่น
แอป Yay มีพฤติกรรมที่แตกต่างออกไปเล็กน้อย ผู้ใช้หลายคนชี้ให้เห็นว่า เย้ คัดลอกแพ็กเกจที่สร้างเสร็จแล้วไปยัง /var/cache/pacman/pkg/ หลังจากคอมไพล์เสร็จแล้ว แพ็กเกจ AUR ของคุณก็จะอยู่ในตำแหน่งเดียวกับแพ็กเกจอย่างเป็นทางการที่จัดการโดย pacman ซึ่งสะดวกดี แต่ในอีกแง่หนึ่งก็หมายความว่า "ข้อดีก็คือ..." เหยียบย่ำสิ่งที่คุณได้กำหนดไว้ PKGDEST en /etc/makepkg.confซึ่งบางคนมองว่าเป็นการไม่เคารพต่อโครงสร้างโดยรวมของระบบ
สำหรับผู้ใช้ทั่วไปแล้ว นี่มักไม่ใช่เรื่องใหญ่ แต่ถ้าคุณค่อนข้างพิถีพิถันเกี่ยวกับการจัดระเบียบไฟล์ไบนารีบนเครื่องของคุณ นี่อาจเป็นเหตุผลหนึ่งที่ทำให้เราชอบพฤติกรรมที่ "สะอาดกว่า" ของ paru มากกว่าหรืออย่างน้อยก็ควรรับรู้ว่าผู้ช่วยแต่ละคนกำลังทำอะไรกับพัสดุของคุณ
ระดับการบำรุงรักษาและกิจกรรมของแต่ละโครงการ
ในการอภิปรายต่างๆ แนวคิดนี้ได้แพร่กระจายออกไปว่า yay ถูกทิ้งร้างหรือล้าสมัยไปแล้ว และ paru คือตัวเลือกที่เหมาะสมที่จะใช้แทนคำกล่าวนี้ส่วนหนึ่งมาจากข้อเท็จจริงที่ว่าหนึ่งในนักพัฒนาที่เกี่ยวข้องกับ yay ได้ย้ายไปมุ่งเน้นที่ paru และในวิดีโอและโพสต์บางส่วนได้ตีความว่าโครงการ yay ได้ล่มสลายหรือถูกปล่อยทิ้งร้าง
ผู้ใช้งานและนักพัฒนาหลายรายได้ออกมาปฏิเสธเรื่องราวดังกล่าวอย่างเด็ดขาด: เย้ ยังคงมีการบำรุงรักษาอย่างต่อเนื่องอยู่มีการอัปเดตโค้ดในคลังเก็บโค้ดอย่างสม่ำเสมอและมีชุมชนขนาดใหญ่คอยสนับสนุนอยู่ อันที่จริง ความหงุดหงิดของเหล่าผู้ดูแลบางส่วนเกิดจากการที่ได้ยินคำพูดซ้ำๆ ว่า "เย้ มันตายแล้ว" โดยที่ไม่มีใครสนใจที่จะตรวจสอบสถานะที่แท้จริงของโครงการเลย
ในขณะเดียวกัน ก็เป็นความจริงที่ว่า ปารุแสดงให้เห็นถึงกิจกรรมที่สูงมากและต่อเนื่องบางครั้งอาจให้คะแนนสูงกว่า "เยี่ยม" เล็กน้อยในบางช่วงเวลา ซึ่งเป็นเรื่องที่สมเหตุสมผล เนื่องจากเป็นโครงการที่ค่อนข้างใหม่ กระตือรือร้นที่จะปรับปรุงรายละเอียดต่างๆ และมีผู้เขียนที่เอาใจใส่และตอบสนองต่อปัญหาและคำขอจากชุมชนอย่างรวดเร็ว
ในทางปฏิบัติ สำหรับผู้ที่ต้องการติดตั้งโปรแกรมเท่านั้น ความแตกต่างในขั้นตอนการทำงานเหล่านี้แทบจะไม่ก่อให้เกิดปัญหาใดๆ ทั้งสองโปรเจกต์ยังคงพัฒนาอย่างต่อเนื่อง โดยได้รับการแก้ไขข้อบกพร่องและเพิ่มฟีเจอร์ใหม่ๆและไม่มีอะไรบังคับให้คุณต้องละทิ้งความยินดีเพราะกลัวว่ามันจะล้มเหลวในระยะสั้น
หลักปฏิบัติเกี่ยวกับการรักษาความปลอดภัย การตรวจสอบไฟล์ PKGBUILD และการใช้งาน AUR
จุดสำคัญประการหนึ่งที่แสดงให้เห็นถึงความแตกต่างอย่างชัดเจนในแนวทางปฏิบัติคือ วิธีการที่ผู้เข้าร่วมแต่ละคนใช้ในการทบทวน PKGBUILDsโปรดจำไว้ว่า AUR ไม่ใช่แหล่งเก็บโค้ดอย่างเป็นทางการ: นี่คือสูตรที่ผู้ใช้ส่งเข้ามา และความรับผิดชอบขั้นสุดท้ายในการตรวจสอบสูตรเหล่านั้นเป็นของคุณ
ชุมชน Arch ยืนยันมาโดยตลอดว่า คุณต้องอ่านไฟล์ PKGBUILD ก่อนทำการติดตั้งเพื่อหลีกเลี่ยงสิ่งที่ไม่คาดคิด (สคริปต์ที่เป็นอันตราย การดาวน์โหลดจากแหล่งที่ไม่น่าเชื่อถือ คำสั่งอันตราย ฯลฯ) Paru ซึ่งสอดคล้องกับหลักการนี้ จึงถูกตั้งค่าเริ่มต้นให้แสดงการตรวจสอบนี้และ "บังคับ" ให้คุณให้ความสนใจก่อนที่จะสร้างแพ็กเกจ
เยี่ยมเลย แม้ว่ามันจะช่วยให้คุณตรวจสอบไฟล์ PKGBUILD ได้ด้วยก็ตาม ช่วยให้การไหลเวียน "รวดเร็วและไร้กังวลยิ่งขึ้น" หากคุณต้องการวิธีแก้ปัญหาที่ตรงไปตรงมา นี่เป็นสิ่งที่ดึงดูดใจอย่างมากสำหรับผู้ที่ให้ความสำคัญกับความสะดวกสบายและไว้วางใจผู้ดูแล AUR แต่ก็ทำให้เกิดความเข้าใจผิดว่า "yay" ส่งเสริมให้ "ติดตั้งโดยไม่ตรวจสอบ" มากขึ้น ซึ่งไม่ค่อยเข้ากับแนวคิดที่เน้นความบริสุทธิ์ของ Arch สักเท่าไหร่
อย่างไรก็ตาม สิ่งสำคัญที่ควรจำไว้คือ ไม่ว่าคุณจะใช้ผู้ช่วยแบบใดก็ตาม ทุกอย่างจะผ่าน Makepack และ Pacman ในที่สุดกล่าวอีกนัยหนึ่ง ทั้งสองอย่างช่วยลดภาระงานที่ซับซ้อนลง แต่รูปแบบพื้นฐานยังคงเหมือนเดิม คือ ไฟล์ PKGBUILD ที่กลายเป็นแพ็กเกจซึ่ง pacman จะจัดการและติดตั้ง ความรับผิดชอบในการทำความเข้าใจสิ่งที่คุณกำลังติดตั้งยังคงเป็นของคุณ
การใช้งาน AUR โดยไม่มีผู้ช่วยและบทบาทของ Pac-Man
คำถามที่ถามซ้ำๆ กันนี้ ปรากฏขึ้นในหลายกระทู้ด้วยเช่นกัน: "จะอัปเดตแพ็กเกจ AUR โดยไม่ใช้ตัวช่วยสร้างได้อย่างไร?"คำตอบแบบดั้งเดิม ซึ่งสอดคล้องกับปรัชญาอย่างเป็นทางการของ Arch นั้นชัดเจน: คือการใช้ makepkg ด้วยมือโดยใช้ไฟล์ PKGBUILD ที่เกี่ยวข้อง
PKGBUILD คือสูตรที่กำหนด วิธีการสร้างแพ็กเกจจากซอร์สโค้ดหรือจากไฟล์ไบนารีที่คอมไพล์ไว้ล่วงหน้าเมื่อสร้างแพ็กเกจเสร็จแล้ว pacman จะจัดการการติดตั้งและการบันทึกข้อมูลเช่นเดียวกับแพ็กเกจจากที่เก็บอย่างเป็นทางการ ไม่มีการปฏิบัติพิเศษใดๆ สำหรับการเป็น "AUR" สำหรับ pacman แล้ว เมื่อสร้างแพ็กเกจเสร็จแล้ว มันก็เป็นเพียงแพ็กเกจอีกแพ็กเกจหนึ่งเท่านั้น
ผู้ช่วยอย่างเย่และพารูนั้นก็เป็นเพียงแค่... เพิ่มความสะดวกสบายหลายชั้นเหนือขั้นตอนคลาสสิกอย่าง “ดาวน์โหลด PKGBUILD → สร้างแพ็กเกจ → เล่น Pacman”โปรแกรมเหล่านี้ทำหน้าที่ค้นหา แก้ไขปัญหาการพึ่งพาของไฟล์ ดาวน์โหลดและคอมไพล์อัตโนมัติ และเพิ่มเมนูและตัวเลือกที่เป็นประโยชน์ แต่ไม่ได้เข้ามาแทนที่หรือแก้ไขบทบาทของ pacman ในฐานะผู้จัดการระบบส่วนกลาง
นั่นเป็นเหตุผลที่ผู้ใช้รุ่นเก่าบางคนภูมิใจที่ไม่เคยใช้ผู้ช่วย และปกป้องวิธีการแบบแมนนวลว่าเป็นวิธีที่โปร่งใสและควบคุมได้มากที่สุด ในขณะที่ผู้ใช้ส่วนใหญ่เลือกที่จะประหยัดเวลาและพึ่งพาเครื่องมือแบบแมนนวล โดยเชื่อว่าระบบอัตโนมัติจะทำให้ชีวิตง่ายขึ้นโดยที่ไม่สูญเสียการควบคุมสิ่งที่กำลังทำไปโดยสิ้นเชิง
Paru และ yay ในดิสทริบิวชันที่พัฒนาต่อยอดจากระบบปฏิบัติการนี้: EndeavorOS, Manjaro, Artix…
ในดิสโทรอย่าง EndeavourOS คำว่า "yay" มักจะมาพร้อมกับข้อความนี้ ติดตั้งไว้ล่วงหน้าหรือแนะนำให้เป็นผู้ช่วยหลักสิ่งนี้ส่งผลกระทบอย่างมากต่อประสบการณ์ของผู้ใช้ใหม่ ซึ่งมักจะเลือกใช้ yay โดยไม่คิดมาก เพราะระบบและเอกสารทางการระบุไว้เช่นนั้น ต่อมาพวกเขาอาจค้นพบ paru และพิจารณาว่าการเปลี่ยนแปลงนี้คุ้มค่าหรือไม่
ในการพูดคุยบางครั้งภายในชุมชน EndeavourOS เอง ได้มีการหยิบยกประเด็นต่อไปนี้ขึ้นมา พวกเขาควรเริ่มรวม Paru ไว้เป็นค่าเริ่มต้นผู้ใช้และสมาชิกทีมหลายคนตอบกลับมาว่า พวกเขาไม่เห็นความจำเป็นที่จะต้องทำเช่นนั้น เพราะ yay ยังคงเป็นเครื่องมือที่แข็งแกร่ง บำรุงรักษาดี และเป็นที่รู้จักกันดี ดังนั้น ในระยะสั้นและระยะกลาง ดูเหมือนว่าจะไม่มีการเปลี่ยน yay เป็น paru ในดิสทริบิวชันนี้ในวงกว้าง
ในระบบปฏิบัติการที่พัฒนาต่อยอดจาก Arch Linux อื่นๆ (เช่น Artix, Manjaro เป็นต้น) สถานการณ์ก็คล้ายคลึงกัน: สิ่งสำคัญคือต้องสามารถเข้าถึง AUR และความสามารถในการใช้งานผู้ช่วยได้แต่สุดท้ายแล้วคุณจะเลือกใช้ตัวไหนนั้น มักขึ้นอยู่กับคำแนะนำในเอกสาร สิ่งที่ชุมชนแนะนำ หรือสิ่งที่คุณลองใช้เป็นครั้งแรกแล้วได้ผลดี
นอกจากนี้ ยังมักแนะนำให้เปิดใช้งานแหล่งเก็บข้อมูลภายนอก เช่น วุ่นวาย-AUR เพื่อให้การติดตั้งตัวช่วยเหล่านี้ทำได้ง่ายขึ้นโดยไม่ต้องคอมไพล์จาก AUR เอง คู่มือบางฉบับจึงอธิบายวิธีการเตรียมระบบ เพิ่มที่เก็บเหล่านี้ แล้วติดตั้ง yay หรือ paru โดยตรงในรูปแบบแพ็กเกจไบนารี หลีกเลี่ยงขั้นตอนการสร้างด้วยตนเองในขั้นต้น
ติดตั้งและใช้งานผู้ช่วยทั้งสองได้เลย
ตัวเลือกหนึ่งที่ผู้ใช้หลายคนชื่นชอบ โดยเฉพาะผู้ที่กำลังทดลองใช้งาน คือ ติดตั้งทั้ง yay และ paru และลองใช้ทั้งสองแบบไปสักระยะหนึ่ง วิธีนี้จะช่วยให้คุณใช้ yay สำหรับงานที่คุณทำเป็นประจำอยู่แล้ว และทดลองใช้ paru สำหรับงานเฉพาะด้าน โดยเปรียบเทียบความรู้สึกและการใช้งานบนฮาร์ดแวร์ของคุณเอง
เนื่องจากเครื่องมือเหล่านี้อาศัย pacman และ makepkg พวกเขาไม่ก้าวล้ำหรือทำลายระบบด้วยการอยู่ร่วมกันคุณสามารถติดตั้งแพ็กเกจด้วยโปรแกรมหนึ่ง แสดงรายการอัปเดตด้วยอีกโปรแกรมหนึ่ง และทำงานต่อไปได้โดยไม่มีปัญหาใหญ่ ตราบใดที่คุณรู้วิธีใช้งาน เมื่อคุณเข้าใจความต้องการของคุณแล้ว หากต้องการทำให้ทุกอย่างง่ายขึ้น คุณสามารถเก็บเฉพาะโปรแกรมที่คุณชอบที่สุดและถอนการติดตั้งโปรแกรมอื่นได้
ในบางกรณีเฉพาะเจาะจง แนะนำให้ติดตั้ง ปารุใช้เย่ (เนื่องจาก yay ติดตั้งมาพร้อมกับระบบปฏิบัติการอยู่แล้ว) ลองใช้ดู และถ้าคุณชอบ ก็เปลี่ยนสคริปต์ ชื่อย่อ และการตั้งค่าต่างๆ ไปใช้ paru แล้วก็ไม่ต้องใช้ yay อีกต่อไป แต่ขอย้ำอีกครั้งว่า ไม่มีข้อผูกมัดทางเทคนิคใด ๆ ที่ต้องทำการเปลี่ยนแปลงนี้มันเป็นเรื่องของรสนิยมและปรัชญามากกว่า
ในทางกลับกัน ก็มีบางคนที่ชอบใช้วิธี "แบบดั้งเดิม" เสมอ: ติดตั้งตัวช่วยต่างๆ จาก AUR โดยใช้คำสั่ง makepkgเพื่อรักษาความสอดคล้องกับปรัชญา Arch ที่บริสุทธิ์และเรียบง่าย ไม่ว่าในกรณีใด ผลลัพธ์สุดท้ายก็เหมือนกัน คือ คุณจะได้ตัวช่วยใช้งานที่ทำให้การใช้ AUR ง่ายขึ้น
เมื่อพิจารณารายละเอียดปลีกย่อยทั้งหมดเหล่านี้แล้ว สิ่งที่ชัดเจนก็คือ ผู้ช่วยทั้งสองตัวนี้สามารถตอบสนองความต้องการของผู้ใช้ Arch ทั่วไปได้เป็นอย่างดีParu ช่วยทำให้การโต้ตอบกับ AUR เป็นไปโดยอัตโนมัติ อัปเดตระบบให้ทันสมัยอยู่เสมอ และมอบความสะดวกสบายบางอย่างที่ Pacman ไม่มีให้ Paru เน้นไปที่การปรับปรุงแก้ไขและประสิทธิภาพที่ดียิ่งขึ้นเล็กน้อย ในขณะที่ Yay มอบประสบการณ์การพิมพ์ที่คุ้นเคยและรวดเร็ว พร้อมความน่าเชื่อถือที่ได้รับการพิสูจน์มานานหลายปี ซึ่งเป็นเหตุผลว่าทำไมผู้คนจำนวนมากจึงยังคงภักดีต่อ Yay แม้จะมีทางเลือกใหม่ๆ ออกมาแล้วก็ตาม
