2014-09-25 10 views
7

필자는 현재 설치 프로세스가 수동으로 작성된 Makefile으로 구성되어 있고 /etc/에 구성 파일을 설치하는 여러 개의 Perl 작성 (유닉스 계열) 응용 프로그램을 유지합니다.Dist :: Zilla 기반 Perl 모듈 (또는 app)이/etc /에 파일을 설치하는 방법?

정말 Dist::Zilla를 사용하여 자신의 발전을 전환하고 싶습니다하지만 지금까지 내가 /etc/로 주어진 파일을 넣어 나를 수있는 DIST : 질라 플러그인 또는 기능을 발견하지 않은 경우 make install (또는 ./Build install 경우 ExtUtils::MakeMaker 대신 Module::Build을 사용하는 경우) 내 응용 프로그램을 설치하는 로컬 관리자가 실행합니다.

순수한 ExtUtils::MakeMaker으로 추가 대상을 MY::postamble에 정의하고 install 대상을 depend { install => … } 속성을 통해 대상으로 지정할 수 있습니다. 유사한 것을하고 있지만, dzil build 경유로는 아마도 충분할 것이지만, 나는 더 분명한 방법을 고맙게 생각할 것입니다.

직각 접근법은 응용 프로그램이 /etc/ 아래의 파일을 필요로하지 않도록하는 것이지만 Dist :: Zilla로 전환하기 위해 빌드 시스템을 변경하려는 경우에도 실제 코드에서 많이 변경되는 것처럼 보입니다. 지금 당장.

궁금한 점 : 현재 Dist :: Zilla로 전환 할 때 염두에 두어야 할 두 가지 응용 프로그램은 xen-toolsunburden-home-dir입니다.

+0

사실 데비안 패키지에있는'debian/install' 파일과 같은 것은 깔끔합니다. –

답변

2

복잡한 모듈 설치 프로그램을 Dist :: Zilla로 이식하려면 선호하는 설치 관리자에 따라 MakeMaker::Custom 또는 ModuleBuild::Custom 플러그인을 사용하는 것이 좋습니다. 이것들은 기존의 Makefile.PL 또는 Build.PL을 유지하고 Dist :: Zilla에 의존성과 같은 필요한 비트를 꽂아 둘 수 있습니다.

+0

Hrm. Dist :: Zilla :: Plugin :: MakeMaker :: Custom의 개요에 따르면, 많은 상용구 코드가 필요하다. (그 중 실제로 모든 것이 실제로 무엇인지는 모르겠다.) 하나의 기능이'Makefile '이라는 것을 보았습니다.PL'은'dzil 빌드 '없이도 작동하지만, 필자는 그것을 전혀 필요로하지 않고 단지'## {$ ALL_EXCEPT_WriteMakefile ##}'을 가지고 기대했던 몇 줄의 추가 코드를 추가하여'% args', 마지막으로'WriteMakefile (% args);', 즉 전체 파일에 몇 줄을 더한 것이 아니라 추가 한 내용을 더한 것입니다. –

+1

@XTaran, 보일러 플레이트의 대부분은 전통적인'Makefile.PL'이 어떻게 생겼는지입니다. 'unless ... eval' 물건이하고있는 모든 것은 [ExtUtils :: MakeMaker] (https://metacpan.org/pod/ExtUtils::MakeMaker)의 이전 버전과의 호환성을 추가하는 것입니다. 대신 ExtUtils :: MakeMaker의 최소 버전을 올리거나이 기능을 전혀 사용하지 않을 수 있습니다. – cjm

+0

고마워요, 그렇게 짧아지고 이해하기 쉬워집니다. :-) 그 정보를 POD에 추가하는 것이 좋습니다. 단락 앞에 "물론 Makefile.PL이 더 복잡하거나이 플러그인이 필요하지 않습니다." 어느 정도 복합체가 될 수 있지만 덜 복잡하지는 않습니다. 그리고 아마도 "should"를 "could"으로 대체하고 "또는 당신은이 플러그인이 필요하지 않습니다"라는 문구를 버리십시오. –

4

가장 좋은 방법은 Perl 배포본의 /etc에 파일을 설치하지 않는 것입니다. cpan 클라이언트 (또는 설치 사용자)가 거기에 설치할 수있는 권한을 가질 수는 없으며 시스템에 여러 개의 Perls가 설치 될 수 있으므로 각각 하나가 다른 설치의 /etc 파일을 손상시킬 수 있습니다. 후속 설치로 인해 파일을 덮어 쓰는 것을 방지 할 수 없기 때문에 잃어 버리지 않으려는 설정 데이터를 두지 마십시오.

응용 프로그램에서 파일을 찾을 수 있지만 해당 경로를 사용자 지정하도록 허용하는 경우 구성 파일을 /etc /에 넣을 수 있습니다 (예 : 테스트 시스템에서 로컬 디렉토리의 파일 찾기, 또는 사용자의 홈 디렉토리에서).

읽기 전용 모듈 관련 데이터를 설치하는 경우 Perl의 가장 좋은 방법은 Perl 설치 특정 위치에 설치하는 것이며 해당 모듈은 File::ShareDir::Install입니다. [ShareDir] 플러그인 Dist::Zilla::Plugin::ShareDir을 사용하여 Dist::Zilla에서 사용할 수 있습니다. 심지어 [@Basic] 플러그인 번들에 포함되어 있기 때문에 dist.ini에서 [@Basic]을 사용하는 경우 데이터 저장소 파일을 배포 저장소의 share/ 디렉토리에 놓는 것 이외에는 아무 것도 할 필요가 없습니다 .

코드에서 sharedir의 내용에 액세스하려면 File::ShareDir을 사용하십시오.

+1

또 다른 방법 : 사용자가'/ etc /'에 글을 쓸 수있게하고, 사용자가'/ etc /'에 글을 쓸 수있게하고 디폴트를 오버라이드하고 싶을 때만 허용한다. 디폴트를 오버라이드하고 싶지 않다면, 배포본이'share /'디렉토리에 들어있어 무엇이든 사용하면 행복합니다. 당신은 아무런 울음 소리없이 의지 할 수 있습니다. –

+0

물론 쓰기 권한이없는 경우 구성 파일의 설치 경로를 구성 할 수 있어야합니다. 나는 겹쳐 쓰는 것에 대해 아직 좋은 아이디어가 없다. 지금까지는 두 가지 애플리케이션에 대한 배포 패키지 관리자가 처리했지만 패키지 작성자는 구성 파일을 '$ PREFIX/etc /'에 설치하기 위해 애플리케이션을 필요로하거나 선호합니다. 읽기 전용 모듈 별 데이터는 다른 주제이지만 사실은 간단합니다. –