ฉันควรใส่แอปพลิเคชันลงใน / usr / local หรือ / usr / local / share หรือไม่

21

"มาตรฐาน" คืออะไรฉันควรใส่แอปพลิเคชัน (ไม่ใช่แค่ไบนารี แต่เป็นการกระจายทั้งหมด) ไปที่ / usr / local หรือ / usr / local / share

ตัวอย่างเช่นสกาล่าหรือ weka - มันมีตัวอย่างไบนารีห้องสมุดและอื่น ๆ ดังนั้นมันจะเป็น

/usr/local/scala-2.9.1

หรือ

/usr/local/share/scala-2.9.1

เนื่องจากฉันเป็นผู้ดูแลระบบคนเดียวมันจึงไม่ใช่เรื่องใหญ่สำหรับฉัน แต่ฉันชอบที่จะใช้สิ่งที่ใช้กันอย่างแพร่หลายไม่ใช่กับประเพณีของตัวเอง

สำคัญ:ฉันไม่ได้ถามเกี่ยวกับกรณีที่คุณควรแยกแอปเป็น / usr / local / bin, / usr / local / lib และอื่น ๆ ค่อนข้างฉันถามเกี่ยวกับกรณีเมื่อคุณต้องเก็บหนึ่งไดเรกทอรีหลักสำหรับใบสมัครทั้งหมด

software-installation directory-structure application

— greenoldman
แหล่งที่มา

6

ฉันคิดว่า / opt เป็นธรรมเนียมปฏิบัติมากกว่าในบริบทแบบนี้

— Faheem Mitha

@Faheem Mitha จุดดีมาก ขอบคุณที่ฉันพบคำอธิบาย "ไดเรกทอรีต้นไม้" / opt / 'ผู้ให้บริการ' คล้ายกับวิธีที่ Windows จะติดตั้งซอฟต์แวร์ใหม่ไปยังไดเรกทอรีต้นไม้ของตัวเอง C: \ Windows \ Progam Files \ "ชื่อโปรแกรม" จากlinuxtopia.org/ online_books / linux_beginner_books / …คุณช่วยกรุณาโพสต์ความคิดเห็นของคุณเป็นคำตอบได้ไหมดังนั้นฉันจะทำเครื่องหมายเป็นคำตอบหรือไม่ขอบคุณ

— greenoldman

@greenoldman: โปรดทราบด้วยว่าการเก็บไฟล์ทั้งหมดไว้ใน dir เดียวไม่ใช่วิธี "มาตรฐาน" ในการติดตั้งแอปพลิเคชั่นใน Unix /optแน่นอนคำตอบที่ถูกต้อง แต่มันไม่ได้ "ใช้กันอย่างแพร่หลาย" โดยซอฟต์แวร์ Unix / Linux แบบดั้งเดิม มีเหตุผลที่ดีในการแยกไฟล์ของคุณในหลาย dirs และยังแตกต่าง/usrจาก/usr/local

— MestreLion

ตัวอย่างเช่นการเก็บไฟล์ที่เรียกใช้งานได้ทั้งหมดจากแอพพลิเคชั่นทั้งหมดในครั้งเดียว/usr/bin(หรือ/usr/local/bin) อนุญาตให้คุณ $ PATH เข้าถึงซอฟต์แวร์ทั้งหมดโดยไม่จำเป็นต้องแก้ไขมันสำหรับแต่ละซอฟต์แวร์แนวคิดที่ไม่มีใน Windows

— MestreLion

19

ฉันคิดว่า / opt เป็นมาตรฐานที่มากกว่าในบริบทประเภทนี้ ส่วนที่เกี่ยวข้องในมาตรฐานระบบแฟ้มลำดับชั้นอ้างอิงด้านล่าง

การกระจายอาจติดตั้งซอฟต์แวร์ใน / opt แต่ต้องไม่แก้ไขหรือลบซอฟต์แวร์ที่ติดตั้งโดยผู้ดูแลระบบในระบบโดยไม่ได้รับการยินยอมจากผู้ดูแลระบบในระบบ

ation เหตุผลการใช้ / เลือกใช้ซอฟต์แวร์เสริมเป็นวิธีปฏิบัติที่ได้รับการยอมรับอย่างดีในชุมชน UNIX System V Application Binary Interface [AT&T 1990] ซึ่งเป็นไปตาม System V Interface Definition (รุ่นที่สาม) ให้โครงสร้าง / opt คล้ายกับที่กำหนดไว้ที่นี่

Intel Binary Compatibility Standard v. 2 (iBCS2) ยังมีโครงสร้างที่คล้ายกันสำหรับ / opt

โดยทั่วไปข้อมูลทั้งหมดที่จำเป็นในการสนับสนุนแพ็คเกจบนระบบจะต้องมีอยู่ภายใน / opt / รวมถึงไฟล์ที่ตั้งใจจะคัดลอกไปยัง / etc / opt / และ / var / opt / เช่นเดียวกับไดเรกทอรีที่สำรองไว้ใน / opt

ข้อ จำกัด เล็กน้อยเกี่ยวกับการแจกแจงโดยใช้ / opt เป็นสิ่งที่จำเป็นเนื่องจากความขัดแย้งเป็นไปได้ระหว่างซอฟต์แวร์ที่ติดตั้งกระจายและซอฟต์แวร์ที่ติดตั้งในเครื่องโดยเฉพาะในกรณีของชื่อพา ธ คงที่ที่พบในซอฟต์แวร์ไบนารีบางตัว

โครงสร้างของไดเรคทอรี่ด้านล่าง / opt / จะอยู่ในระดับสูงสุดของซอฟต์แวร์แม้ว่าจะแนะนำให้ติดตั้งแพ็คเกจใน / opt // และทำตามโครงสร้างที่คล้ายกับแนวทางสำหรับ / opt / แพ็คเกจ เหตุผลที่ถูกต้องสำหรับการเบี่ยงเบนจากโครงสร้างนี้มีไว้สำหรับแพ็คเกจสนับสนุนซึ่งอาจมีไฟล์ติดตั้งใน / opt // lib หรือ / opt // bin

— Faheem Mitha
แหล่งที่มา

5

คุณควรใช้/usr/local/shareสำหรับไฟล์ที่ไม่เฉพาะเจาะจงกับสถาปัตยกรรม / OS เฉพาะ

หลังจากนั้นมันก็ขึ้นอยู่กับคุณว่าคุณแจกจ่ายไฟล์ระหว่าง subdirs ที่มีอยู่ของ/usr/localหรือถ้าคุณสร้างไดเรกทอรีใหม่ทุ่มเทใน/usr/local( แต่หลังจะไม่ได้มีอยู่แล้วในการปฏิบัติการPATHที่LD_LIBRARY_PATH, หรือMANPATH)

ดูFHS

— symcbean
แหล่งที่มา

ขอขอบคุณ. ดังนั้นถ้ามันเป็นการเปรียบเทียบจาก Windows มันควรจะเป็น / usr / local / SPECIAL_APP และข้างในควรมีไดเรกทอรีย่อยใช่ไหม?

— greenoldman

@greenoldman: ไม่ ไม่มีการเปรียบเทียบจะพอดีเพราะ Windows และ Linux ใช้รูปแบบที่แตกต่างกันใน Windows คุณมักจะเก็บไฟล์ทั้งหมดใน dir เดียวที่อยู่ในลินุกซ์ที่คุณมักจะแยกพวกเขามากกว่าbin, share, libฯลฯ

— MestreLion

3

จนกระทั่งกลายเป็นเรื่องธรรมดาที่เกิดขึ้นตามปกติคือ/opt/usr/local/lib/<package>

— เท็ดดี้
แหล่งที่มา

1

จากสิ่งที่ฉันอ่าน / opt เป็นเรื่องธรรมดาไม่เพียง แต่ใช้กันอย่างแพร่หลาย แต่นี่ไม่ใช่เรื่องแปลกถ้าคุณคิดถึงจำนวนของแพ็คเกจที่มีใน repositories

— greenoldman

0

เมื่อติดตั้งแอปพลิเคชั่นในเครื่องมีหลายตัวเลือกขึ้นอยู่กับวิธีที่คุณต้องการเข้าถึงและอัปเดต นอกจากนี้ควรสังเกตว่าวิธีการบางอย่างมีลักษณะเหมือนระบบที่คุณมีอยู่แล้วและบางวิธีมีความเฉพาะเจาะจงมากขึ้น ฉันขอแนะนำว่าโซลูชันที่ "ดีที่สุด" คือโซลูชันที่ทำให้การจัดการง่ายขึ้น

ฉันแบ่งคำตอบนี้ตามจำนวนแพ็คเกจเพื่อทำการติดตั้งแบบกำหนดเอง การแยกจะขึ้นอยู่กับประสบการณ์ของฉันเอง ประสบการณ์เหล่านี้มีน้ำหนักเวลาที่ใช้ในการจัดการแพคเกจและความเสี่ยงของ messing up ฉันไม่ได้หมายความว่าฉันมีความรู้เกี่ยวกับมาตรฐานทั่วไป แต่หมายถึงสิ่งนี้เป็นจุดอ้างอิงที่ควรพิจารณาเมื่อทำการตัดสินใจ

สำหรับแพคเกจเพียงไม่กี่ฉันจะวางแพคเกจ/optเสริมที่พวกเขาออกไปจากทุกอย่างอื่นดังนั้นจึงไม่มีอะไรสามารถทำให้พวกเขาสับสนและพวกเขาสามารถทำสิ่งอื่นขึ้น นี่เป็นวิธีที่ฉันใช้กับ NAS ของฉัน อย่างไรก็ตามวิธีนี้ทำให้ไบนารีไม่ได้อยู่ใน PATH ของคุณดังนั้นคุณจะต้องทำการเพิ่มด้วยตนเอง วิธีนี้ใช้งานได้ดีหากมีแพ็คเกจเพียงไม่กี่ชุดเท่านั้นที่จะติดตั้ง แต่ค่อนข้างจะยุ่งเหยิงหากมีหลายแพ็คเกจ

การอัปเดตที่นี่นั้นค่อนข้างง่ายเพราะคุณเพียงแค่เขียนทับไดเรกทอรี

ข้อดี:

ง่าย
รวดเร็วในการติดตั้ง
ไม่มีโอกาสที่จะส่งผลกระทบต่อส่วนอื่น ๆ ของระบบ
ถอนการติดตั้งนั้นง่ายเหมือนการติดตั้ง

จุดด้อย:

ค่อนข้างน่าเบื่อหากจำนวนแพ็คเกจที่จะติดตั้งมีขนาดใหญ่
ทำให้PATHดูรก

สำหรับแพ็กเกจมากกว่าสองสามตัวฉันขอแนะนำให้ใช้/usr/local/<your package>และการเชื่อมโยงแบบ sym-executable จาก/usr/local/binหรือ/usr/local/sbinขึ้นอยู่กับว่าคุณต้องการสิทธิ์รูท สิ่งนี้จะช่วยให้คุณไม่ต้องเปลี่ยน PATH ทุกครั้งที่มีสิ่งใหม่เพิ่มเข้ามาดังนั้น PATH จึงยังคงสะอาดอยู่ นี่เป็นวิธีที่ฉันใช้กับแล็ปท็อป Arch ของฉันสำหรับแพ็คเกจที่ไม่ใช่แพคแมนและแพ็คเกจ AUR ทั้งหมด

การอัปเดตทำได้โดยเขียนทับไดเรกทอรีแพ็คเกจและตรวจสอบว่า symlink นั้นยังใช้งานได้และแก้ไขได้หากไม่มี

ข้อดี

ไม่ทำให้PATHยุ่ง
ไม่ส่งผลกระทบต่อระบบฐาน
ยังง่ายมากที่จะลบส่วนเสริมทั้งหมดและกลับสู่ระบบฐานที่สะอาด

จุดด้อย:

ทำงานได้มากขึ้นในการตั้งค่า
การลบแพ็กเกจเดียวเท่านั้นมีบางสิ่งที่ต้องทำ

สำหรับแพคเกจจำนวนมาก เช่นนี้ไม่ใช่กรณีที่คุณต้องการฉันจะให้มันสั้น ฉันจะแนะนำแพคเกจแยกลงbin, lib, shareฯลฯ /usr/localและติดตั้งให้พวกเขา นี่คือการรักษาโครงสร้างที่สะอาด คุณสามารถระบุผู้ที่สามารถเขียนได้ที่ไหนและอีกมากมาย ตัวอย่างเช่นคุณไม่ต้องการให้คนอื่นนอกจากรูทปรับเปลี่ยนปฏิบัติการ

ที่นี่การอัปเดตจะยุ่งยากเล็กน้อยตามที่คุณต้องการเขียนไปมากกว่าไดเรกทอรีเดียว ฉันขอแนะนำให้ทำบรรจุภัณฑ์ทั้งหมดและให้ผู้จัดการบรรจุภัณฑ์จัดการส่วนที่เหลือ

การแชร์

shareไดเรกทอรีตัวเองเป็นอิสระสำหรับไฟล์สถาปัตยกรรมตามที่ระบุไว้ใน Faheem ของการเชื่อมโยงและสถาปัตยกรรมไฟล์ขึ้นควรไปlib, lib32, lib64ฯลฯ

— Lauri Tšili
แหล่งที่มา

การให้คำแนะนำตามจำนวนแพ็คเกจไม่เป็นประโยชน์ ฉันจะรู้ได้อย่างไรว่ากลุ่มไหนเป็นแพ็คเกจของฉัน

— Alois Mahdal

นอกจากนี้เมื่อคุณพูดว่า "ขอแนะนำ" แหล่งอ้างอิงหรือรัฐอย่างชัดเจนว่าเป็นคำแนะนำของคุณ (ฉันคาดเดาหลัง ... ?)

— Alois Mahdal

และโดยวิธีการที่ฉันไม่เห็นว่าใน / เลือกจะมีโอกาสน้อยกว่าในสิ่งที่ทำให้แอปของคุณยุ่งเหยิงกว่าเมื่อมันแพร่กระจายไปยัง / usr ฯลฯ การส่งแอปอื่น ๆ ไปยังแอพอื่น ๆ ติดตั้งสคริปต์

— Alois Mahdal

แน่นอนว่ามันเกี่ยวกับการตั้งชื่อที่ทำให้สิ่งต่าง ๆ สับสน มันเป็นสิ่งที่ฉันมีประสบการณ์ในอดีตและนั่นคือเหตุผลที่ฉันต้องการเก็บ "พิเศษ" ของฉันออกไปจากทุกอย่างอื่น ฉันยังไม่ต้องการให้สิ่งต่าง ๆ ดูน่าเกลียด

— Lauri Tšili

และใช่คุณถูกต้องเกี่ยวกับ "ขอแนะนำ" ตามที่คุณอาจเห็นจากคำตอบของฉันฉันได้ใช้ "ฉันจะแนะนำ" ทุกที่อื่น ตอนนี้ฉันได้แก้ไขการสะกดและแก้ไขว่าทำไมฉันถึงขอแนะนำบางอย่าง อีกครั้งมันเป็นเพียงมุมมองของฉันและไม่ได้หมายความว่าเป็นคำตอบที่ชัดเจน

— Lauri Tšili