포장은 상황에 따라 결정된다

묘사

이 PR은 현식 설정이 FPM에 전달될 패키지 이름에 대한 지원을 추가하여 먼저 구축하거나 실행할 때 의존항으로 설치할 필요가 없습니다.의존 항목의 아키텍처를 지정하고 목표가 RPM인 경우 이 작업은 필수입니다.만약 이 PR이 없다면, "i686"으로 의존 관계를 지정하면, puppet는 매우 기쁘지만, RPM은 설치된 의존 관계를 해결할 수 없습니다.의존항을 '(x86-32)' 로 지정하면 RPM은 만족스럽지만, puppet은 실패했습니다.
만약 홍보가 받아들여진다면, 나는 그에 상응하여 비키를 갱신할 것이다.

토론 #1

당신은 나에게 예를 들어 문제를 설명할 수 있습니까?또한 --no-deps 옵션이 도움이 되었습니까?

토론 #2

@bernd
다음은 문제가 있는 레시피의 예를 보여 주는 요점입니다.https://gist.github.com/brian-oconnell/0d1c722a0e306aad3cc9
다음은 내가 실행하는 명령의 요점입니다.https://gist.github.com/brian-oconnell/4250b689fefbe95162bf
다음은 잘못된 출력입니다.https://gist.github.com/brian-oconnell/c83037c09fedc1673c76
이것은 fpm-cook-install-deps 명령에 실패했습니다. 이 명령은 구축 의존항과 일반 의존항을 동시에 설치하려고 하기 때문입니다.나는 구축을 실행하기 위해 의존항을 구축해야 한다.

토론 #셋

의 또 다른 침입성이 비교적 적을 수 있는 옵션은 구축 의존항만 설치하기 위해 cli 변경 (태그 또는 새 명령) 을 하는 것이다.
만약 당신이 원한다면, 나는 공관

토론 #4

을 제출할 수 있습니다. 업데이트에 감사 드립니다.나는 다음 며칠 안에 이 문제를 처리할 시간을 좀 찾아야 한다.

토론 #5

저는 이 문제와 Puppet과dependency 설치 중의 모든 다른 문제를 고려하여 자동dependency 설치를 삭제하는 것이 가장 좋다고 결정했습니다.
이 기능을 제거하기 위해 #122에서 PR을 준비했습니다.원인에 대해서도 더 상세한 해석이 있다.한 번 보십시오. 당신의 의견을 알 수 있도록, 관계. 감사합니다.

토론 #6

마치https://github.com/bernd/fpm-cookery/pull/122의존항 설치를 삭제하지 않는 방향으로 발전하고 있습니다.
심사숙고한 끝에, 나는 우리가 내가 개술한 방식으로 DSL을 확장하기를 원하는지 확실하지 않다. 왜냐하면 이것은 사용자의 곤혹을 증가시킬 것이라고 생각하기 때문이다.
나는 확실히 역사 설계 문제가 하나 있다.왜 fpm Coordy는 패키지 단계, 심지어 deps 단계의 의존항 검증을 설치하는 동안 구축 의존항과 의존항을 함께 통합합니까?나는 왜build deps를 설치해야 하는지 이해하지만, 내가 처리하는 프로젝트에 대해 왜 패키지 deps를 설치해야 하는지 이해하지 못한다.또는 설치하려면 build deps를 로 설정하지 않는 이유가 있습니다.
따라서 만약에 우리가 본 PR에서처럼 DSL을 확장하고 싶지 않다고 가정하고 상술한 문제의 답안에 근거하여 나는 두 가지 전진의 길을 보았다.니 생각을 알려줘.
1. 의존항을 설치하고 포장하는 동안build dependens와 dependens의 합병을 삭제합니다.(이것은 상술한 문제의 답안에 달려 있다).
2. build deps만 설치할 새 명령 추가
3.'x86-32'의존항을 자동으로'i686'의존항으로 변환한 다음puppet에 전달한다.
# 버나드: 네가 어떤 것을 더 좋아하는지 알게 해줘. 나는 위의 어떤 선택이나 네가 제시한 다른 선택을 위해 홍보를 하고 싶어.

토론 #7

It seems that PR #122 is heading towards not removing the dependency installation.

그래, 내가 그 홍보의 피드백을 받은 후, 이 기능은 너와 다른 사람들에게 매우 가치가 있는 것 같다.이것도 내가 약간의 피드백을 얻기를 희망하는 것이다. 이렇게 하면 내가 그것을 합병할지 말지를 결정할 수 있다.(소통을 놓쳤어요...)

Why does fpm-cookery merge the build_depends and depends together during dependency verification for the package phase or even the install-deps phase?

depends는 실행할 때 필요한 것(그리고 라이브러리 구축에 필요한 것), build_depends은 도구 구축 등 패키지, -dev|devel는 프로젝트 구축에 필요한 패키지에 사용된다는 생각이다.
예:

class Foo < FPM::Cookery::Recipe
  build_depends 'libpng12-dev'
  depends 'libpng12-0'
end

libpng12-0와 libpng12-dev는 모두 소프트웨어 구축에 필요한 것이다. 이것이 바로 이 두 dependecy listst가 합병된 이유이다.depends에서 지정한 가방만 fpm에 의존항으로 전달되고 가방에 기록됩니다.
나는 이것이 사람을 곤혹스럽게 할 수도 있다는 것에 동의한다. 특히 아직 문서가 없기 때문이다.
당신이 건의한 세 가지 옵션:
1. 기존의 식단을 많이 깨뜨릴 수 있다.적어도 제가 쓴 것들.미소:
2. 이것은 기존 설계도를 깨뜨리지 않는 해결 방안일 수 있다.1: 우리는 기본적으로 의존항 설치를 비활성화하는 것도 고려해야 한다.(이것은 기존의 설정을 다시 깨뜨릴 수도 있어, 응)
저한테는 너무 구체적으로 들려서 피하고 싶어요.

토론 #8

설치depends와 build_depends는 둘 다 필요하기 때문에 포장 문제로 보인다.즉libpng12-dev 패키지는 libpng12-0에 의존해야 하기 때문에 설치libpng12-dev도 설치libpng12-0한다.debian-dev 패키지가 실행 중인 패키지를 도입하지 않았는지 확인하시겠습니까?
나는 rpm세계에서 왔고, 나는 deb세계를 모른다.

토론 #9

내 생각에 libpng*의 예는 나쁜 예이다wink: 주요 생각은 depends 과 build_depends 에서 의존항을 복제할 필요가 없다는 것입니다.

토론 #10

이 두 목록에 변수를 사용해서 사용할 수 있습니다. 만약에 실행 라이브러리를 명확하게 정의해야 한다면 -dev 패키지가 공유 라이브러리를 포함하는 실행 패키지에 들어가지 않았다면 패키지는 오류라고 생각합니다.

all_depends = %w[libpng0 libjpeg6]

depends all_depends
build_depends all_depends, 'libpng-dev', 'libjpeg-dev'

참고로 rpmworld에서 공유 라이브러리 의존 항목은 라이브러리 SONAME에 따라 자동으로 생성됩니다.

➔ rpm -q libpng --provides
libpng16.so.16()(64bit)
libpng16.so.16(PNG16_0)(64bit)

$ rpm -q --requires libicns | grep png
libpng16.so.16()(64bit)
libpng16.so.16(PNG16_0)(64bit)

토론 #11

앞에서 말한 바와 같이libpng의 예는 가장 좋은 것이 아니라 순전히 허구이다.debian에서 libpng12-dev 패키지를 의존항으로 라이브러리에 가져옵니다.

토론 #12

https://github.com/bernd/fpm-cookery/pull/126커밋 옵션 #2.

토론 #13

imho #126이 합쳐지면 기본 fpm 요리 실행은build deps만 설치하는 것으로 변경해야 합니다(옵션2).어떻게'운행시'deps를 설치하지 않은 상태에서 fpm 요리를 실행합니까?

토론 #14

@glensc 댓글 좀 설명해 주시겠어요?왜 사용자로 하여금 포장 단계에서 DEP가 없으면 부족하다고 지정하게 합니까?나는 모든 사용자 사례를 이해할 수 있는 충분한 프로젝트 역사가 없다.

토론 #15

@brian oconnell 구축할 때 fpm Coordy를 사용하고runtime Dependesdepends 명령을 설치하지 않으려면 어떻게 계속해야 합니까?

토론 #16

@glensc는 당신이 이미 지정했다고 믿습니다. 구축하기 전에 명령줄에 dep가 없습니다.그것은 종합 가방에 적용되지 않지만, 나는 이 문제를 열었다https://github.com/bernd/fpm-cookery/issues/124관련했어https://github.com/bernd/fpm-cookery/pull/125복구해 드리겠습니다.

토론 #17

@brian oconnell 하지만--설치build_depends와 depends 둘을 건너뛰는 DEP가 없나요?나는 build_depends가 여전히 만족스럽기를 바란다.

토론 #18

@glensc는 fpm 쿡 패키지를 실행하기 전에 deps가 없습니다. fpm 쿡 설치를 실행하고 deps를 구축할 것입니다.명령이https://github.com/bernd/fpm-cookery/pull/126
이것은 너의 문제를 해결할 수 있니?

토론 #19

@brian oconnell, 하지만 패키지가 필요합니다. 따라서 다시 호출해야 합니다. fpm-cook package install deps를 호출합니다. 따라서:
1. fpm cook 설치build deps.
2. fpm cook 패키지-deps

토론 #20

@glensc가 올바르지 않습니다. 이것은 두 가지 절차가 될 것입니다. 이 점에서 마지막에 패키지를 받을 수 있습니다.

토론 #21

한 번의 통화라면 --no-runtime-deps 옵션을 추가하는 것을 더 좋아합니까?
저는 정말 더 선택하고 싶지만.https://github.com/bernd/fpm-cookery/pull/116#issuecomment- 136155073

토론 #22

@glensc-hmmm. @bernd의 의견을 얻어야 할 것 같습니다.

토론 #23

나는 fpm-cook package의 자동 의존항 설치를 사용하지 않는 것이 가장 좋다고 생각한다. 왜냐하면 우리는 현재 install-deps와 install-build-deps를 사용할 수 있기 때문이다.의존 항목을 설치하려면 슈퍼 사용자 권한이 필요하기 때문에 임무를 분리하는 것이 가장 좋다고 생각합니다.
그래서 제 조언은:
1. fpm-cook package에 따라 생성/실행 시 자동 설치 비활성화
2. --install-build-deps 옵션을 추가하여 fpm-cook package상의 구축 의존항만 설치합니다.
3. --install-deps 옵션을 추가하여 fpm-cook package에 구축 및 실행 시 의존 항목을 설치합니다.
4. 옵션이 더 이상 필요하지 않으므로 제거--no-deps어떤 피드백이 있나요?

토론 #24

@bernd 당신의 조언은 제가 FPM으로 요리하는 방식과 일치합니다.

토론 #25

일리가 있으니 하세요.

토론 #26

:+1:

토론 #27

저는 #131에 공관을 만들었습니다.나는 지금 이 공관을 닫을 테니 그곳에서 평론과 평론을 해 주십시오.감사합니다!