3. 포트에 기여하기

3.1. 관리되지 않는 포트를 책임지기

3.1.1. 관리되지 않는 포트 선택하기

관리되지 않는 포트를 책임지는 것은 참여하기에 좋은 방법입니다. 관리되지 않는 포트는 누군가가 자원봉사로 작업할 때에만 업데이트되고 고쳐집니다. 관리되지 않는 포트는 많이 있습니다. 여러분이 정기적으로 사용하는 포트를 책임지는 것부터 시작해 보면 좋을 것입니다.

관리되지 않는 포트는 그 MAINTAINERports@FreeBSD.org로 설정되어 있습니다. 관리되지 않는 포트와 그것들의 현재 문제점 및 problem reports에 대한 목록은 Ports Monitoring System에서 찾아볼 수 있습니다.

어떤 포트는 그 의존성 관계 때문에 다른 많은 포트에 영향을 미칠 수 있습니다. 일반적으로, 우리는 사람들이 그러한 포트를 관리하기 전에 약간의 경험을 해볼 것을 원합니다.

INDEX라고 이름붙여진 포트의 마스터 인덱스를 살펴보면 포트의 의존성 관계를 파악할 수 있습니다. (파일의 이름은 FreeBSD의 릴리즈에 따라 다를 수 있습니다; 예를 들어, INDEX-8.) 일부 포트는 기본 INDEX 빌드에는 포함되지 않는 부가적인 의존성 관계를 가지고 있습니다. 우리는 여러분이 다른 포트의 Makefile을 살펴봄으로써 이러한 포트를 찾아낼 수 있기를 기대합니다.

3.1.2. 포트를 책임지는 방법

우선 관리자로서의 책임에 대해 명확히 이해해야 합니다. 또 Porter's Handbook을 읽어 보세요. 여러분이 편안하게 다룰 수 있을 범위를 넘어서서 무리할 필요는 없습니다.

여러분은 원한다면 관리되지 않는 포트의 관리 권한을 언제든지 요청할 수 있습니다. 그냥 MAINTAINER을 여러분의 이메일 주소로 설정하고 해당 내용을 PR(Problem Report)로 보내 주세요. 포트에 빌드 에러가 있거나 업데이트가 필요하다면, 같은 PR에 그러한 수정 내용을 포함해도 좋습니다. 많은 커미터들은 FreeBSD에 남긴 흔적이 없는 누군가에게 관리 권한을 부여하고 싶어하지 않기 때문에, 이는 도움이 되는 행동일 것입니다. 빌드 오류를 고치거나 포트를 업데이트하는 PR을 제출하는 것은 이러한 흔적을 남기는 가장 좋은 방법입니다.

여러분의 PR을 ports 카테고리와 change-request 클래스로 설정한 뒤 제출해 주세요. 커미터가 여러분의 PR을 검토하고, 수정 사항을 커밋하고, 마침내 PR을 종료시킬 것입니다. 이 과정은 종종 시간이 걸릴 수도 있습니다(커미터들 역시 자원봉사자들입니다 :).

3.2. 포트 관리자를 위한 도전 과제

이 항목은 포트가 관리되어야 하는 이유 및 포트 관리자의 책임에 대해 설명해줄 것입니다.

3.2.1. 포트의 관리가 필요한 이유

포트를 만드는 일은 일회성 작업입니다. 포트가 최신 상태인지, 그리고 빌드 및 실행이 문제없이 되는지를 확인하는 일은 지속적인 관리 노력이 필요합니다. 관리자는 그들의 시간 중 일부를 이 목표를 달성하는 데 투자하는 사람들입니다.

포트에 관리가 필요한 가장 주요한 이유는 FreeBSD 커뮤니티에 최신의 많은 3rd party 소프트웨어를 제공하기 위함입니다. 추가적인 목표는 각각의 포트들이 지속적으로 개선되어도 계속 포트 컬렉션 프레임워크 안에서 동작할 수 있도록 유지시키기 위함입니다.

관리자로서, 여러분은 다음의 도전 과제들을 담당할 필요가 있습니다:

  • 새로운 소프트웨어 버전 및 업데이트. 포팅된 소프트웨어에 대해서는 언제든지 새로운 버전과 업데이트가 있을 수 있고, 최신의 소프트웨어를 제공하기 위해서 이들은 포트 컬렉션에 포함될 필요가 있습니다.

  • 종속된 포트가 수정되었을 경우. 여러분의 포트에 종속된 포트가 크게 수정되었을 경우, 여러분의 포트 역시 올바르게 동작하기 위해 업데이트되어야 할 수 있습니다.

  • 종속된 포트에 영향을 미치는 수정 사항들. 만일 여러분이 관리하는 포트에 다른 포트가 의존하고 있다면, 여러분은 여러분의 포트를 수정하기 위해 다른 관리자들과 공동 작업을 해야 할 수도 있습니다.

  • 다른 사용자, 관리자 및 개발자와의 소통. 관리자로서의 역할 중 하나는 지원자의 역할입니다. 일반적인 지원을 제공해야 할 필요는 없습니다 (여러분이 그렇게 한다면 우리는 환영할 것입니다). 여러분이 제공해야 하는 것은 FreeBSD 환경에서 여러분의 포트에 나타나는 특정한 문제들의 해결에 도움을 주는 것입니다.

  • 버그 추적하기. 포트는 FreeBSD 환경에서 특정하게 나타나는 버그의 영향을 받을 수도 있습니다. 여러분은 그러한 버그들이 제보되었을 때 조사하고, 찾아내고, 이들을 고쳐야 합니다. 포트 컬렉션에 넣기 전에 포트를 전체적으로 테스트해보는 것은 더욱 좋습니다.

  • 포트의 기반 및 정책의 수정. 때때로 포트와 패키지를 빌드하는 데 사용되는 시스템이 업데이트되거나 그 기반에 영향을 미치는 새로운 제안이 나오기도 합니다. 여러분은 여러분의 포트가 영향을 받아 업데이트를 필요로 하게 될 경우를 위해 이러한 변화에 대해 알고 있어야 합니다.

  • 베이스 시스템의 수정. FreeBSD는 지속적으로 개발되고 있습니다. 소프트웨어, 라이브러리, 커널 또는 심지어 정책이 바뀌면 포트 역시 자연스럽게 수정이 필요해질 수 있습니다.

3.2.2. 관리자로서의 책임

3.2.2.1. 여러분의 포트를 최신 상태로 유지하세요

이 항목은 여러분의 포트를 최신 상태로 유지시키기 위한 과정을 설명하고 있습니다.

이것은 개괄적인 내용입니다. 포트를 업그레이드하는 것에 대한 더 자세한 정보는 Porter's Handbook에서 찾아볼 수 있습니다.

  1. 업데이트 지켜보기

    소프트웨어의 새로운 버전, 업데이트 그리고 보안 수정 사항을 위해 upstream vendor를 주시하세요. 이를 위해서 announcement 메일링 리스트 또는 뉴스 웹 페이지가 도움이 될 것입니다. 사용자들이 종종 여러분에게 연락해서 여러분의 포트가 언제 업데이트될 것인지에 대해 문의할 수 있습니다. 만약 여러분이 다른 이유로 바쁘거나 지금 업데이트할 수 없는 어떤 이유가 있다면, 그들에게 업데이트 제출을 도와줄 수 있는지 요청해 보세요.

    여러분은 또한 FreeBSD Ports Version Check로부터 여러분의 포트에 대한 새 버전의 distfile이 사용 가능하다는 자동 이메일을 받을 수도 있습니다. 그 시스템에 대한 (앞으로의 이메일을 그만 받는 방법을 포함한) 더 많은 정보는 해당 메시지에 제공될 것입니다.

  2. 수정 사항을 적용시키기

    변경 사항이 사용 가능해지면, 포트에 적용시켜 주세요. 원본 포트와 업데이트된 포트 사이의 패치를 생성할 수 있어야 할 것입니다.

  3. 검토 및 테스트하기

    여러분의 수정 사항 전체를 검토하고 테스트해보세요:

    • 가능한 많은 플랫폼과 아키텍처에서 여러분의 포트를 빌드, 설치 그리고 테스트해보세요. 하나의 브랜치 혹은 플랫폼에서 잘 작동하던 포트가 다른 곳에서 실패하는 것은 드문 일이 아닙니다.

    • 여러분의 포트의 의존성 관계가 완전한지 점검해 주세요. 권장되는 방법은 여러분의 포트를 tinderbox로 설치해 보는 것입니다. 더 자세한 정보를 위해서는 resources를 참조해 주세요.

    • 패킹 리스트가 최신 상태인지 확인하세요. 이는 새로운 파일 및 디렉토리를 추가하는 일과 사용되지 않는 내용을 제거하는 일을 포함합니다.

    • portlint(1)를 이용하여 여러분의 포트를 검토하세요. portlint를 사용하는 방법에 대한 중요한 사항을 위해서는 resources를 참조하세요.

    • 여러분의 포트에 대한 수정 사항이 다른 포트를 고장내는 일이 있을지에 대해 고려해 주세요. 만약 그럴 가능성이 있는 경우에는, 해당 포트의 관리자와 수정 내용을 조율해 주세요. 이는 여러분의 업데이트가 shared library의 버전에 수정을 가하는 경우에 특히 중요합니다; 이 경우, 적어도, 종속된 포트는 PORTREVISION bump를 얻어서 portmaster 또는 portupgrade(1)와 같은 자동화된 도구에 의해 자동으로 업데이트될 수 있도록 할 필요가 있습니다.

  4. 수정 내용 제출하기

    수정 사항에 대한 설명 및 원본과 수정본 사이의 변경 내역을 포함한 패치를 담은 PR을 통해 여러분의 업데이트를 보내 주세요. 좋은 PR을 작성하는 방법에 대한 내용은 Writing FreeBSD Problem Reports를 참조해 주세요.

    참고:

    포트 전체에 대한 shar(1) 아카이브를 제출하지는 말아 주세요; 그 대신에, diff(1) -ruN를 사용해 주세요. 이렇게 하면, 정확히 무엇이 수정되었는지 커미터들이 훨씬 쉽게 파악할 수 있습니다. Porter's Handbook에 있는 Upgrading 항목에서 더 많은 정보를 찾아볼 수 있습니다.

  5. 기다리기

    때가 되면 커미터가 여러분의 PR을 담당할 것입니다. 이는 몇 분, 또는 몇 주가 소요될 수 있습니다 — 그러므로 그동안 기다려 주세요.

  6. 피드백하기

    만약 커미터가 여러분의 수정 사항에서 문제점을 찾아내면, 그들은 대체로 여러분에게 다시 알려줄 것입니다. 신속한 답변은 여러분의 PR이 빨리 커밋되는 데 도움이 되고, 어떤 문제를 해결하고자 할 때 대화의 흐름을 유지하는 데에도 좋습니다.

  7. 그리고 마지막으로

    여러분의 수정 사항이 커밋되고 여러분의 포트가 업데이트될 것입니다. 그런 다음 PR은 커미터에 의해 닫힐 것입니다. 그것으로 끝입니다!

3.2.2.2. 여러분의 포트가 지속적으로 올바르게 빌드되는지를 확인해 주세요

이 항목은 포트가 올바르게 빌드되지 못하도록 하는 문제를 찾아내고 고치는 방법에 대한 것입니다.

FreeBSD는 포트 컬렉션이 -STABLE 가지에서 동작하는 것만을 보장합니다. FreeBSD는 포트 컬렉션이 -STABLE 가지에서 동작하는 것만을 보장합니다.

FreeBSD 설치본의 대부분은 (i386 아키텍처라고 불리는) PC-호환 기종에서 동작하기 때문에, 우리는 여러분이 포트를 그 아키텍처에서 동작하도록 작업할 것을 기대합니다. 포트가 amd64 아키텍처에서 네이티브로 동작한다면 더욱 좋습니다. 만약 여러분이 이러한 기종을 가지고 있지 않다면 얼마든지 도움을 요청해도 괜찮습니다.

참고:

x86 이외의 장치에서의 빌드 실패에 대한 대부분의 이유는 프로그램 작성자가, 예를 들어, 포인터를 int로 가정했거나, 또는 상대적으로 오래된 gcc 컴파일러가 사용된 경우입니다. 점점 더 많은 프로그램 작성자들은 이러한 가정을 제거하기 위해 그들의 코드에 대해 재작업을 하고 있습니다 — 그러나 작성자가 그들의 코드를 적극적으로 유지보수하지 않는다면, 여러분은 스스로 이 일을 해야 할 수도 있습니다.

여러분의 포트가 성공적으로 빌드될 수 있도록 하기 위해 여러분은 다음의 작업을 해야 합니다:

  1. 빌드 실패 주시하기

    빌드에 실패하거나 오래된 포트가 있는지 살펴보기 위해 pkg-fallout@FreeBSD.orgdistfiles scanner로부터의 메일을 확인해 주세요.

  2. 정보 모으기

    여러분이 문제점을 인식하면, 그것을 고치는 데 도움이 되는 정보를 모으세요. 여러분이 문제점을 인식하면, 그것을 고치는 데 도움이 되는 정보를 모으세요. 만약 그러한 빌드 실패가 사용자에 의해 여러분에게 보고되었다면, 문제점을 진단하는 데 도움이 될 수 있는 다음과 같은 정보를 요청하세요:

    • 빌드 로그

    • 포트를 빌드하는 데 사용되는 명령어 및 옵션들 (/etc/make.conf에 세팅된 옵션들을 포함)

    • pkg_info(1)를 통해 보여지는, 그들의 시스템에 설치된 패키지들의 목록

    • uname(1) -a을 통해 보여지는, 그들의 현재 FreeBSD의 버전

    • 그들의 포트 컬렉션이 마지막으로 업데이트된 때

    • 그들의 포트 트리와 INDEX가 마지막으로 업데이트된 때

  3. 문제점을 조사하고 해결책을 찾아보기

    불행히도 이를 위한 간단한 프로세스는 없습니다. 그렇지만, 기억하세요: 뭔가 잘 안 풀린다면, 도움을 요청하세요! FreeBSD 포트 메일링 리스트는 시작하기에 좋은 곳이고, 상부의 개발자들은 대개 대단히 잘 도와줍니다.

  4. 수정 내용 제출하기

    포트를 업데이트할 때와 마찬가지로, 여러분은 이제 수정 사항을 적용하고, 검토하고 테스트하고, PR로 수정 사항을 제출하고, 필요하다면 피드백을 제공해야 합니다.

  5. 상부의 저자에게 패치 보내주기

    특정한 경우에, 여러분은 포트가 FreeBSD에서 동작하도록 하기 위해 패치를 만들어야 합니다. 일부 (그러나 모두는 아닌) 상부의 작성자들은 다음 릴리즈에 그러한 패치를 그들의 코드에 반영할 것입니다. 그렇게 되면, 이는 다른 BSD 기반 시스템 사용자들에게 도움이 될 뿐만 아니라 중복된 작업을 할 노력을 절약해줄 수도 있습니다. 적용 가능한 패치를 작성자에게 보내 주는 호의를 베푸는 것을 고려해 보세요.

3.2.2.3. 여러분의 포트에 관련된 버그 보고와 PR을 살펴 보세요

이 항목은 버그를 찾아내고 고치는 방법에 대한 것입니다.

FreeBSD에 특정한 버그는 일반적으로 FreeBSD에는 적용되지 않는 빌드 및 런타임 환경을 가정하기 때문에 일어납니다. 여러분이 이런 유형의 문제를 마주하게 될 가능성은 낮지만, 이것은 더 미묘한 문제이며 찾아내기 어려울 수 있습니다.

여러분의 포트가 의도한 대로 계속 동작하도록 하기 위해 여러분은 다음의 작업들을 해야 합니다:

  1. 버그 보고에 응답하기

    버그는 Problem Report database를 통한 이메일로 여러분에게 보고될 것입니다. 버그는 또한 사용자들에 의해 여러분에게 직접적으로 보고될 수도 있습니다.

    여러분은 PR 및 다른 보고에 대해 14일 이내로 응답해야 합니다만, 그렇게 오래 걸리지는 않도록 노력해 주세요. 단지 여러분이 해당 PR에 대해 작업하기까지 시간이 더 필요하다는 답장만이라도, 가능한 한 빨리 응답할 수 있도록 노력해 주세요.

    만약 여러분이 14일이 지나도록 응답하지 않았다면, 다른 커미터는 maintainer-timeout을 통해 여러분이 응답하지 않은 PR로부터 커밋할 수 있습니다.

  2. 정보 모으기

    만약 버그를 보고한 사람이 수정 사항을 제공하지 않았다면, 여러분은 그 수정을 하기 위한 정보를 모을 필요가 있습니다.

    만약 버그를 재현할 수 있다면, 여러분은 필요한 정보의 대부분을 스스로 모을 수 있습니다. 그렇지 않다면, 버그를 보고한 사람에게 다음과 같은 정보들을 모아줄 것을 요청하세요:

    • 그들의 행동에 대한 자세한 설명, 예상했던 프로그램의 행동과 실제 행동

    • 버그를 발생시키기 위해 입력했던 데이터의 복사본

    • 그들의 빌드 및 실행 환경에 대한 정보 — 예를 들어, 설치된 패키지들의 목록과 env(1)의 출력값

    • Core dumps

    • Stack traces

  3. 잘못된 보고를 배제하기

    일부 버그 제보는 잘못되었을 수도 있습니다. 예를 들어, 사용자가 단순히 프로그램을 잘못 사용했을 수 있습니다; 또는 그들이 설치한 패키지가 오래되었고 업데이트를 필요로 하는 경우일 수도 있습니다. 종종 제보된 버그는 FreeBSD에 국한되는 것이 아닐 수도 있습니다. 이 경우에는 upstream 개발자에게 버그를 제보해 주세요. 만약 여러분이 고칠 수 있을 만한 버그라면, 다음 upstream 릴리즈가 배포되기 전에 여러분이 직접 포트를 패치해서 수정 사항을 적용시켜도 됩니다.

  4. 해결책을 찾아보기

    빌드 오류와 마주쳤다면, 여러분은 문제점에 대한 해결 방안을 찾아볼 필요가 있을 것입니다. 다시 한 번 강조하겠습니다, 뭔가 잘 안 풀린다면 도움을 요청하세요!

  5. 수정 사항을 제출하거나 승인하기

    포트를 업데이트할 때와 마찬가지로, 여러분은 이제 수정 사항을 적용시키고, 검토 및 테스트를 수행하고, 그 내용을 PR로 제출(또는 해당 문제점에 대해 이미 존재하는 PR에 follow-up을 제출)해야 합니다. 다른 사용자가 이미 PR로 변경 사항을 제출했다면, 여러분은 그 변경 사항에 대한 승인 여부를 말하는 follow-up을 보낼 수도 있습니다.

3.2.2.4. 지원을 제공해 주세요

관리자로서의 역할 중 하나는 지원을 제공하는 것입니다 — 이는 소프트웨어 자체에 대한 일반적인 지원이 아니라 — 포트 그리고 FreeBSD에 특정한 특이 사항과 문제점에 대한 지원을 의미합니다. 사용자들은 질문, 제안, 문제점 그리고 패치에 대해서 여러분에게 연락할 수 있습니다. 대부분의 경우 그러한 연락들은 FreeBSD에 특정한 내용들일 것입니다.

종종 여러분은 외교적 수완을 발휘해서, 일반적인 지원을 찾는 사람들에게 적절한 리소스를 알려 주어야 합니다. 이보다는 덜 자주 있는 일이지만, 여러분은 RPM이 왜 최신 상태가 아닌지 또는 소프트웨어를 아무개 리눅스에서 어떻게 실행시키는지에 대해 묻는 사람과 마주칠 수도 있습니다. 그들에게 여러분의 포트가 최신 상태임을 알리고(물론, 그럴 경우에만요!), 그들에게 FreeBSD를 사용해볼 것을 권하는 기회를 잡아 보세요.

종종 사용자와 개발자들은 여러분을 (여러분의 시간을 귀중히 여기는) 바쁜 사람으로 여기고 여러분을 위해 약간의 일을 해줄 수도 있습니다. 예를 들어, 그들은 다음과 같은 일들을 해줄 수도 있습니다:

  • 여러분의 포트를 업데이트하는 PR을 제출하거나 패치를 보내주는 일,

  • 조사하고 아마도 PR에 고친 내용을 제공하는 일, 또는

  • 아니면 여러분의 포트에 대한 수정 사항을 제출하는 일.

이러한 경우에 여러분의 주요 의무는 적절한 때에 응답하는 것입니다. 다시 한번 강조합니다, 관리자의 무응답에 대한 제한 시간은 14일입니다. 이 기간이 지마면 수정 사항은 미승인 상태(unapproved)로 커밋될 것입니다. 그들은 여러분을 위해 이 일을 하는 수고를 했습니다; 그러므로 최소한 신속하게 답변할 수 있도록 노력해 주세요. 그리고 나서 가급적 빨리 이를 검토하고, 승인하고, 그들과 함께 수정 사항을 다듬거나 이에 대해 논의해 주세요.

만약 여러분이 그들의 기여에 감사를 표한다면 (물론 그래야 합니다만) 앞으로 그들이 여러분을 위해 더 많은 일을 해줄 수도 있을 것입니다 :-).

3.3. 고장난 포트를 찾아내고 고치기

관심이 필요한 포트를 찾아보기에 정말 좋은 두 개의 장소가 있습니다.

여러분은 해결되지 않은 PR들을 찾아보기 위해 Problem Report 데이터베이스의 웹 인터페이스를 사용할 수 있습니다. 포트 PR의 대부분은 업데이트이지만, 요약된 내용을 조금만 훑어보면 여러분은 흥미로운 일거리를 찾을 수 있을 것입니다 (sw-bug 클래스는 시작하기에 좋은 장소입니다).

다른 장소는 FreeBSD Ports Monitoring System입니다. 빌드 오류가 있고 관리되지 않는 포트와 BROKEN이라고 표시된 포트에 특히 유의해서 살펴 보세요. 이미 관리되고 있는 포트에 대한 수정 사항을 제출하는 것도 괜찮지만, 관리자가 이미 같은 문제에 대해 작업하고 있는지 물어 보아야 한다는 것을 기억해 주세요.

여러분이 버그나 문제점을 발견했다면, 정보를 모으고, 분석한 뒤 고쳐 보세요! 이미 PR이 존재한다면, 같이 협력하세요. 그렇지 않다면 새로운 PR을 생성하세요. 여러분의 수정 사항은 검토되고 나서, 만약 모든 것이 괜찮다면, 커밋될 것입니다.

3.4. 그만두어야 할 때

여러분의 흥미와 상황이 변함에 따라, 여러분은 여러분의 포트에 대한 일부 (또는 모든) 기여를 계속할 시간이 없을 수도 있습니다. 괜찮습니다! 만약 여러분이 더이상 포트를 사용하지 않거나 투자할 시간이 없거나 관리자로서의 흥미를 잃었다면 우리에게 알려 주세요. 그러면 우리는 일을 진행하면서 여러분의 답변을 기다리지 않고 포트의 문제들에 다른 사람들이 작업하도록 허락할 수 있습니다. 기억하세요, FreeBSD는 자원봉사자들에 의한 프로젝트입니다, 그러므로 포트를 관리하는 일이 이제 재미없다면, 다른 누군가에게 넘겨줄 때입니다!

어느 경우에든지, 여러분이 일정 기간동안 여러분의 포트를 활동적으로 관리하지 않았다면 포트 관리 팀(portmgr)은 여러분의 관리 권한을 초기화시킬 권한을 가지고 있습니다. (현재, 이 기간은 3개월로 정해져 있습니다.) 이것은, 이 기간동안 해결되지 않은 문제나 미루어진 업데이트가 있다는 것을 의미합니다.

3.5. 포트 관리자와 기여자를 위한 자료

Porter's Handbook은 포트 시스템을 여행하는 히치하이커를 위한 안내서입니다. 곁에 두고 자주 살펴 보세요!

Writing FreeBSD Problem Reports은 훌륭한 PR을 작성하고 제출하는 방법에 대해서 설명합니다. 2005년에는 11000개 이상의 포트 PR이 제출되었습니다! 이 글을 따라하는 것은 여러분의 PR을 다루는 데 필요한 시간을 절약해 준다는 점에서 큰 도움이 됩니다.

Problem Report database.

FreeBSD Ports Monitoring System은 빌드 에러 또는 problem report와 같이 포트에 대한 상호 참조 정보를 보여줄 수 있습니다. 여러분이 관리자라면 이러한 정보를 여러분의 포트의 빌드 상태를 확인하는 데 사용할 수 있습니다. contributor로서 여러분은 제대로 동작하지 않고 관리되지 않아서 고쳐질 필요가 있는 포트를 찾아보는 데 사용할 수 있습니다.

FreeBSD Ports distfile scanner는 distfiles를 다운로드할 수 없는 포트를 보여줍니다. 여러분은 이를 여러분의 포트를 확인해 보거나 MASTER_SITES이 업데이트될 필요가 있는 포트를 찾아보는 데 사용할 수 있습니다.

ports-mgmt/poudriere는 포트의 설치, 패키징, 그리고 제거까지의 전 과정을 전체적으로 테스트해볼 수 있는 방법입니다. 관련된 문서는 poudriere home page에서 찾아볼 수 있습니다.

portlint(1)는 여러분의 포트가 많은 중요한 외형적 그리고 기능적 지침을 준수하고 있는지를 검증하는 데 사용되는 애플리케이션입니다. portlint는 단순한 휴리스틱 애플리케이션이기 때문에, 여러분은 이를 지침서의 역할로만 사용해야 합니다. 만약 portlint가 합리적이지 않아 보이는 수정을 제안한다면, Porter's Handbook를 참고하거나 도움을 요청하세요.

FreeBSD ports mailing list는 포트와 관련된 일반적인 논의가 이루어지는 곳입니다. 여기는 도움을 요청하기에 좋은 장소입니다. 여러분은 구독하거나, 리스트 아카이브를 읽어보고 검색해볼 수 있습니다. FreeBSD ports bugs mailing listFreeBSD CVS ports commit list의 아카이브를 읽어보는 것도 흥미로울 수 있습니다.

모든 FreeBSD 문서는 ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ 에서 다운로드받으실 수 있습니다.

문서를 읽고 궁금한 사항이 있으면 <questions@FreeBSD.org>로 질문을 보내 주세요.

이 문서에 대한 질문은 <doc@FreeBSD.org>로 보내 주세요.