☰

특정 버전의 소프트웨어(ABS, pacman 및 Arch Linux) 설치

tag-icon • tag-icon linux arch-linux pacman
특정 버전의 소프트웨어(ABS, pacman 및 Arch Linux) 설치

Arch는 운영 체제(파티션, 파일 시스템, x86) 부팅 프로세스, 부트 로더, MBR/UEFI 내부 및 주변의 다양하고 고급 이동 부분에 대한 개요를 얻기 위한 쉬운 시작점을 찾고 있는 새로운 Linux 사용자를 위한 훌륭한 배포판입니다. , 하드웨어 드라이버, 커널, 커널 공간 및 사용자 공간, 데스크탑 환경, 인터넷 프로토콜, 커널 모듈, ptracing, 가상화 등).

나는 ABS와 팩맨을 좋아한다.이유가 무엇이든지(지원 중단을 지원하는 프로젝트를 구축하거나 단지 내 컴퓨터이기 때문에 B가 아닌 A를 설치하고 싶습니다!)특정 버전일부 소프트웨어(SDK, 드라이버 또는 이상한 라이브러리). 두 가지 옵션이 있습니다:

  1. 당신은 운이 좋고인터넷에 있는 몇몇 무작위 사람들이 패키지 버전은 AUR에서 사용할 수 있습니다.
  2. 오픈 소스 프로젝트인 경우 PKGBUILD를 사용하여 소스에서 빌드할 수 있습니다.

첫 번째 문제는 불일치, 즉 신뢰 문제입니다. 두 번째 문제의 문제점은 프로젝트와 그 엄청난 종속성을 계속해서 컴파일하고 다시 컴파일하는 데 낭비할 추가 사이클이 없다는 것입니다.

"최신 버전만 얻을 수 있습니다"가 기능으로 계속해서 반복되는 것을 보지만 실제로는 "최신"이 더 좋지 않고 종종 필요한 것이 아닙니다. 나는 이것이 단지 패키지 관리자의 작업량을 줄여준다고 생각합니다(어려운 일입니다). 그게 다야. 이것이 pacman/PKGBUILD/ABS의 근본적인 결함입니까, 아니면 Arch 저장소의 선택 사항입니까?

내가 말하는 것이 아니라는 점에 유의하십시오.이전에 설치된 패키지를 다운그레이드(어느가능한캐시에서), 내가 말하는 건특정 버전의 패키지 설치. 그렇게 간단합니다.

Arch(사용자 정의 저장소 없음, 디스크 이미지 없음)를 사용하여 재현 가능한 환경을 만들려고 하는데 매우 번거롭습니다. 실제로 작업이 필요한 아치 사용자는 이 문제를 어떻게 해결할 수 있습니까? 다른 배포판으로 전환하는 것이 유일한 실용적인 옵션입니까?

답변1

모든 항목을 항상 다시 빌드하려는 경우가 아니라면 특정 버전을 요구하는 것은 롤링 릴리스 릴리스의 사용 사례와 거의 반대입니다.

그래서 저는 다음 사항이 걱정됩니다.

  1. 특정 버전, 바람직하게는 배포판과 호환되는 패키지에서 필요한 소프트웨어를 구축하는 방법을 배워야 합니다.
  2. 패키지와 마찬가지로 이에 의존하는 모든 소프트웨어를 빌드하는 방법을 배워야 합니다.
  3. 종속성을 업데이트할 때마다 위의 모든 항목을 직접 다시 빌드해야 합니다.

예를 들어 이 버전에서는 libgnuradio-3.10.7.1을 사용하려고 합니다. 이는 spdlog, libboost, fftw, Qt5, libstdc++, libc…에 따라 다릅니다. 당신의 소프트웨어에서 gr-osmosdr과 gqrx를 사용하고 싶습니다. 둘 다 그것에 의존합니다.

이제 필요한 버전으로 GNU Radio를 빌드하고 설치한 후 libgnuradio-3.10.7.1을 받으세요. 이제 Linux 배포판에 spdlog가 업데이트되었습니다. spdlog가 업데이트되었으므로 libgnuradio를 다시 빌드하여 작업을 계속할 수 있습니다.

libgnuradio에서 내보낸 기호는 spdlog의 기호/유형에 따라 달라지므로 libgnuradio, gqrx 및 gr-osmosdr에 연결된 모든 소프트웨어도 다시 빌드해야 합니다.

이것은 Arch Linux에만 있는 것이 아니라 라이브러리가 작동하는 방식입니다. ABI와 호환되지 않는 모든 업데이트는 연결된 모든 항목을 손상시키며, 라이브러리 작성자가 명시적인 주의를 기울이고 이를 방지하기 위한 조치를 취하지 않는 한 이 동작은 전이적입니다.

그러나 아치의 특징예롤링 릴리스 릴리스이므로 ABI 수준뿐만 아니라 API 수준에서도 파괴적인 방식으로 종속성을 업데이트하는 속도에 제한이 없습니다. 언제든지 libgnuradio-3.10.7.1을 빌드하지 못할 수도 있습니다. 더 이상 libboost에서 사용되기 때문에 헤더가 사라집니다. 아치는 제가 지금까지 사용해본 배포판 중 이 기능을 지원하지 않는 유일한 배포판이라는 점을 덧붙이고 싶습니다.케어종속성 버전 정보 - 다른 배포판과 달리 spdlog를 업그레이드하려면 libgnuradio가 이전 버전의 spdlog를 사용하므로 이를 제거해야 한다고 알려줍니다. 아치에서는 기본적으로 모든 업데이트에는 완전한 시스템 업데이트가 필요합니다.어느모든 것이 계속 작동하도록 업데이트되었습니다. 이는 귀하의 사용 사례에 대한 최악의 경우 기준입니다!

따라서 특정 사용 사례의 경우 Arch는 원하는 배포판이 아닙니다. API를 보장하고 조기 업데이트를 얻기 위해 ABI를 위반하지 않는 배포판을 원합니다.

그래서:

  • 다행스럽게도 인터넷상의 누군가가 AUR에서 이 패키지 버전을 제공하고 있습니다.
  • 오픈 소스 프로젝트인 경우 PKGBUILD를 사용하여 소스에서 빌드할 수 있습니다.

이 중 어느 것도 Arch Linux에서 무엇이든 업데이트할 때마다 전체 종속 트리를 다시 빌드해야 하는 문제를 해결하지 못하며, 오늘 Arch를 기반으로 구축된 항목이 내일도 Arch에 구축될 것이라는 보장은 없습니다. 게다가 AUR은 확실히 추가적인 신뢰를 가져오지 않습니다. 그 목적은 다음과 같습니다.아니요Arch Linux의 공식적으로 유지 관리되고 승인되는 부분입니다.

1 이런 일이 여러 번 일어났습니다. 이것이 바로 현대 C++가 있는 지금 libboost를 사용하는 데 매우 조심스러운 이유입니다.

답변2

보다 안정적인 배포판에서도 특정 패키지 버전이 충분히 오래된 경우에는 설치할 수 없습니다.

배포판에서 아직 제공하지 않는 (이전) 특정 버전이 정말로 필요한 경우 가장 좋은 옵션은 해당 특정 버전이 포함된 배포판 버전으로 컨테이너를 설정하는 것입니다. 그런 다음 컨테이너의 소프트웨어 버전을 고정할 수 있으며, 컨테이너 내에 격리되어 있으므로 컨테이너의 오래된 소프트웨어로 인한 보안 취약성에 대해 (너무 많이) 걱정할 필요가 없습니다.

물론 더 나은 해결책은 문제의 소프트웨어를 현재 버전의 도구 및 라이브러리를 사용하도록 조정하거나 이미 이 작업을 수행하는 최신 버전의 소프트웨어로 업그레이드하는 것입니다.

관련 정보