Vị trí chuẩn để chứa các tệp nguồn phần mềm


16

Có một vị trí tiêu chuẩn trong Linux để giữ các tệp nguồn ví dụ OpenSSL . Tôi đang xây dựng Nginx từ nguồn với phiên bản OpenSSL không mặc định. Tôi cần tải xuống và gỡ bỏ OpenSSL và tôi đã làm nó trong thư mục nhà. Bây giờ, tôi tự hỏi có một vị trí tiêu chuẩn trong Linux /optkhông?


1
Vì terdon đã viết / usr / src là vị trí tiêu chuẩn và ở đây bạn có thể tìm thấy các thư mục cho nguồn kernel (/ usr / src / linux được liên kết với / usr / src / linux-version) và ví dụ X11. Mã nguồn cho các gói được cài đặt cục bộ (/ usr / local) phù hợp hơn với / usr / local / src. Nếu bạn muốn tự xây dựng các gói "thủ công", tạo thư mục src trong homedir của bạn có lẽ là một ý tưởng hay ... Hãy nhớ rằng bạn không nên tải xuống, giải nén hoặc xây dựng dưới dạng root - chỉ cài đặt dưới dạng! Nếu bạn xây dựng gói deb / rpm-gói, thư mục xây dựng tạm thời (ví dụ: under / var / tmp) thường được sử dụng thay thế. TBC
Baard Kopperud

Nếu bạn xây dựng và cài đặt gói - hoặc tự tạo gói (vòng / phút) - chính bạn, bạn thường không cần mã nguồn nữa sau khi cài đặt. Lý do tại sao bạn có thể có mã nguồn cho một số gói - như kernel hoặc X11 - dưới / usr / src (hoặc / usr / local / src nếu nó được tạo cục bộ), chủ yếu là vì bạn có thể cần chúng nếu bạn ' Tự xây dựng (hoặc viết) một số gói phần mềm (ví dụ: một số tệp tiêu đề tối nghĩa từ kernel, phù hợp với thiết lập hệ thống thực tế của bạn). (Tất nhiên, bạn sẽ cần nó nếu bạn muốn xây dựng kernel của riêng mình ...) Nhưng điều này áp dụng cho một vài gói.
Baard Kopperud

Câu trả lời:


20

Bất cứ khi nào bạn tự hỏi mình một cái gì đó như thế này, hãy xem Tiêu chuẩn phân cấp hệ thống tập tin (FHS). Ở đây, bạn sẽ tìm thấy mục sau:

usr / src: Mã nguồn (tùy chọn)

Mục đích

Mã nguồn có thể được đặt trong thư mục con này, chỉ cho mục đích tham khảo

Vì vậy, bạn có thể đặt các tệp nguồn của bạn trong thư mục con của /usr/src. Điều đó nói rằng, đây là một thư mục tùy chọn để bạn thực sự có thể giữ chúng bất cứ nơi nào bạn muốn. Mã nguồn không liên quan sau khi bạn biên dịch nó thành một tệp thực thi, vì vậy hệ thống sẽ không bao giờ yêu cầu nguồn của thứ gì đó có thể truy cập được tại một vị trí cụ thể.

Tóm lại: /usr/srclà một vị trí khá chuẩn nhưng hãy thoải mái lựa chọn nếu bạn thích.


6
Chỉ cần lưu ý rằng bạn thực sự không muốn gặp rắc rối /usr/srctrên hệ thống không phải là Luxux. Các BSD giữ các nguồn hệ thống cơ sở của họ ở đó theo mặc định và bạn không muốn xen kẽ chúng với phần mềm của bên thứ ba. Chỉ cần xây dựng ở $HOMEmột nơi nào đó của bạn ...
Kusalananda

1
Điều tương tự cũng áp dụng cho một số thư mục con của /usr/srccác dẫn xuất Debian, nếu bạn đã cài đặt một số gói nhất định ( gcc-6-source,, binutils-sourcegói DKMS, tiêu đề kernel, v.v.). Trên Debian, có một tính năng hay, nơi bạn có thể tự thêm mình vào srcnhóm sở hữu /usr/src, sau đó chỉ cần viết ở đó như chính bạn (mà không cần sudohoặc bất cứ điều gì).
Stephen Kitt

Và trên Fedora, bạn không nên chạm vào /usr/src/debug/usr/src/kernels(AFAICS).
Stephen Kitt

"Mã nguồn có thể được đặt". Là "nơi được đặt" một lỗi đánh máy, hoặc tôi đang thiếu một cái gì đó?
Faheem Mitha

3
Tôi sẽ đi xa hơn và nói rằng bạn không nên thực sự chạm /usrvào bất kỳ hệ thống nào. Bạn nên đặt mọi thứ vào /usr/local. BSD có phiền bạn sử dụng /usr/local/srckhông?
Muzer

13

/usr/local/srclà một nơi an toàn để giữ mã nguồn và cũng xây dựng nó. FHS nói :

Directory   Description  
src         Local source code

và cũng

Hệ thống phân cấp / usr / cục bộ được quản trị viên hệ thống sử dụng khi cài đặt phần mềm cục bộ. Nó cần được an toàn để không bị ghi đè khi phần mềm hệ thống được cập nhật.

Không rõ "Mã nguồn cục bộ" nghĩa là gì, nhưng rõ ràng hệ thống sẽ không cố gắng đặt bất cứ thứ gì vào /usr/local/src, không giống như /usr/srcvậy, vì vậy dường như có rất ít nhược điểm khi đặt mã ở đó.

Trong thực tế, tôi có của tôi trên một hệ thống tập tin riêng biệt:

Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/data-local_src     79G   46G   30G  61% /usr/local/src

Lưu ý: ít nhất là trên Debian, người dùng của bạn cần được thêm vào staffnhóm để ghi vào /usr/local.


+1 để chỉ ra /usr/local/srctrong khi các câu trả lời khác chỉ thảo luận/usr/src
MattSturgeon

Đối với "mã nguồn cục bộ" nghĩa là gì, nói chung, nó có nghĩa là được kiểm soát bởi sysadmin cục bộ chứ không phải bởi một bản phân phối . Giống như mọi thứ khác theo /usr/local(về lý thuyết). Vì vậy, về cơ bản nó có nghĩa là chính xác những gì bạn mô tả.
MattSturgeon

9

Nếu theo "tiêu chuẩn", bạn có nghĩa là thông thường, thì nơi để giải nén và xây dựng mã nguồn là thư mục chính của bạn. Các tệp như vậy được dự kiến ​​là tạm thời, bị xóa khi bạn hoàn thành hoặc lưu giữ nếu bạn muốn, được tổ chức theo cách bạn muốn. Thư mục nhà của bạn là khu vực của bạn để chơi với tất cả các loại công cụ này.

Nếu bạn muốn giữ chúng sau đó, để tham khảo , " Tiêu chuẩn phân cấp hệ thống tập tin " khuyến nghị /usr/src. Tuy nhiên, đây là một hướng dẫn không phải là một luật; và, nếu bạn đã có thói quen này sau đó mạo hiểm vào một hệ thống không phải là Linux, bạn có thể gây rắc rối bằng cách tuân theo nó. Ví dụ: trên hệ thống BSD, các nguồn hệ thống cơ sở được giữ ở đó và bạn thực sự không muốn gây rối với chúng. Ngay cả trên Linux, bạn có thể gặp rủi ro trộn lẫn với bất kỳ nguồn nào được lưu trữ bởi các nhà quản lý gói, điều không mong muốn.

Tôi khuyên bạn nên tránh /usr/srctổng thể. Không có lợi ích rõ ràng để giữ bất cứ điều gì ở đó, và rủi ro tiềm ẩn nếu bạn nhầm lẫn ý nghĩa dự định của nó.


5

Bạn có thể sử dụng /usr/srcvì nơi này âm thanh hợp lý và phân phối dựa trên vòng / phút sử dụng nó để lưu trữ nội dung của các gói srpm. Nhưng bất cứ nơi nào khác như /opt, /usr/local, ~/srclà tốt


"phân phối dựa trên vòng / phút sử dụng nó để lưu trữ nội dung của các gói srpm." Đó chính xác là lý do tại sao bạn không nên lưu trữ các nguồn không phân phối của riêng mình ở đó và sử dụng / usr / local. - "Đó phải là một nơi tốt để lưu trữ đồ đạc, với tất cả các xe nâng này xung quanh dường như có cùng quan điểm ...."
rackandboneman
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.