pkg
pkg copied to clipboard
freebsd
pkg always installs newest dependency in repo
At $work we have a unique-but-unavoidable situation where due to poor development practices some dev teams are in a situation which requires multiple versions of the same package in a package repo. This worked fine with pkg_tools and RPM/yum, but this is a blocker for moving some projects onto newer FreeBSD systems. Trying to work around this with duplicate ports and PKGPREFIX/SUFFIX would be extremely difficult: potentially hundreds of new slave ports to do this.
I've created a very simple PoC. I picked the first duplicate package I could see in one of the internal repos which I knew had no dependencies (pkgconfig -- please understand it's merely an example of the unexpected behavior) and used that to build this PoC.
Attached is a tarball, duplicate_poc.tar.gz. Inside is a sample pkg repo and a simple port to demonstrate the problem:
$ find duplicate_poc/ duplicate_poc/ duplicate_poc/repo duplicate_poc/repo/All duplicate_poc/repo/All/pkgconf-1.2.2_1.txz duplicate_poc/repo/All/pkgconf-1.3.5,1.txz duplicate_poc/repo/All/deptest-1.0.txz duplicate_poc/repo/digests.txz duplicate_poc/repo/packagesite.txz duplicate_poc/repo/meta.txz duplicate_poc/ports duplicate_poc/ports/devel duplicate_poc/ports/devel/deptest duplicate_poc/ports/devel/deptest/Makefile duplicate_poc/ports/devel/deptest/pkg-descr
The port Makefile is like this:
$ cat Makefile # Created by: Mark Felder# $FreeBSD$ PORTNAME= deptest PORTVERSION= 1.0 CATEGORIES= devel MASTER_SITES= # none DISTFILES= # none MAINTAINER= [email protected] COMMENT= Dependency Test RUN_DEPENDS= pkgconf=1.2.2_1:devel/pkgconf NO_BUILD= yes NO_INSTALL= yes NO_ARCH= yes .include
When building the port, it correctly fetches pkgconf-1.2.2_1 to satisfy the RUN_DEPENDS, but when installing the package from the repo it chooses the wrong one:
$ sudo pkg install deptest Updating local repository catalogue... local repository is up-to-date. All repositories are up-to-date. pkg: deptest-1.0: duplicate dependency listing: pkgconf, ignoring pkg: deptest-1.0: duplicate dependency listing: pkgconf, ignoring Checking integrity... done (0 conflicting) The following 2 package(s) will be affected (of 0 checked): New packages to be INSTALLED: deptest: 1.0 pkgconf: 1.3.5,1 Number of packages to be installed: 2 Proceed with this action? [y/N]: y [1/2] Installing pkgconf-1.3.5,1... [1/2] Extracting pkgconf-1.3.5,1: 100% [2/2] Installing deptest-1.0... $ sudo pkg info -d deptest deptest-1.0: pkgconf-1.2.2_1 $ pkg search -x pkgconf pkgconf-1.2.2_1 Utility to help to configure compiler and linker flags pkgconf-1.3.5,1 Utility to help to configure compiler and linker flags
This is a problem for our devs as they need to be able to declare specific package versions for dependencies.
I understand this is a unique situation and not something we would ever encounter in the public ports tree, but can this be fixed?
Thanks duplicate_poc.tar.gz
Em, i'm not sure, but how you did create repo with with two packages with same pkgname? I thought what pkgname is unique key
You put the files in a folder and run the "pkg repo" command.
I have an in-house team that has their own tool different from poudriere. It has deficiencies, but solves other problems they have encountered with their development/deployment processes.
This method of multiple packages in a repo with the same pkgname but different versions works without issue on Linux and old FreeBSD pkg_tools, but doesn't work with pkgng. This is preventing them from being able to embrace modern FreeBSD.
This is not something we would ever allow in the public FreeBSD package repositories, but there is no reason why a vendor or private FreeBSD package repo couldn't have all of their software releases packaged up in a single repo.
FWIW, I run a large ecosystem based on APT, and the ability to have multiple versions of the same package in a repository that users can select between (in case the newer version is broken, for example, so they don't have to go through massive contortions to downgrade manually while reporting a bug) is something people really really enjoy "just working".
@bapt That isn't at all the same. The feature that other package managers have here isn't to allow you to install multiple non-conflicting versions of the same package at once, but to allow the repositories to host multiple conflicting versions of the same package, allowing the package dependency resolver to potentially resolve an old version--one that would need to single-handedly satisfy constraints from other packages--as well as allowing users to "pin" themselves to an old version (which you can mentally model as effectively allowing another global constraint) if they feel the latest release is broken for them while they report the bug upstream.