Failure case is shown below, and make -V BUILD_DEPENDS -C emulators/linux-c6 comes up empty. It is in all-depends, but portmaster can't seem to find it there. If all other ports managers get this right then please reassign to portmaster. ---------------- [mandree@apollo /usr/ports.svn]$ portmaster -d emulators/linux-c6 ===>>> Port directory: /usr/ports/emulators/linux-c6 ===>>> Gathering distinfo list for installed ports ===>>> Gathering dependency list for emulators/linux-c6 from ports ===>>> Launching child to install accessibility/linux-c6-atk ===>>> emulators/linux-c6 >> accessibility/linux-c6-atk (1/1) ===>>> Port directory: /usr/ports/accessibility/linux-c6-atk ===>>> Launching 'make checksum' for accessibility/linux-c6-atk in background ===>>> Gathering dependency list for accessibility/linux-c6-atk from ports ===>>> Launching child to install emulators/linux_base-c6 ===>>> emulators/linux-c6 >> accessibility/linux-c6-atk >> emulators/linux_base-c6 (2/2) ===>>> Port directory: /usr/ports/emulators/linux_base-c6 ===>>> This port is marked IGNORE ===>>> pkg(8) must be version 1.3.8 or greater, but you have 1.3.7. You must upgrade pkg(8) first ===>>> If you are sure you can build it, remove the IGNORE line in the Makefile and try again. ===>>> Update for emulators/linux_base-c6 failed ===>>> Aborting update ===>>> Update for accessibility/linux-c6-atk failed ===>>> Aborting update
I agree. Will want bapt's ack too though.
PKG_DEPENDS has been created exactly not to add pkg in build depends. In my opinion portmaster/portupgrade has to grow with the knowlegde of PKG_DEPENDS otherwise FETCH_DEPENDS and PATCH_DEPENDS also needs to be added to BUILD_DEPENDS
Proposed patch at https://reviews.freebsd.org/D927
I don't see why we need to keep adding features such as PKG_DEPENDS if we already have a working BUILD_DEPENDS. I find PKG_DEPENDS gratuitous. pkg _is_ a build requisite the way the b.p.m is set up, so there is little point in keeping it out of BUILD_DEPENDS. FETCH_DEPENDS and PATCH_DEPENDS are different stories because these pertain to long-standing features of ports. However, PKG_DEPENDS has been shoehorned in recently without visible reason (to me, for one). What problem is this "PKG_DEPENDS split out from BUILD_DEPENDS" trying to solve that _waiving_ a _version_ requirement could not solve? The version requirement is only there because pkg was inflicted on the world before it was mature. This is to some extent unavoidable because only the wide testing base will unveil all of its bugs. I'd say bitch about an old version and print blinky red warnings, but otherwise stay out of the user's way and continue the build, and forget about version enforcement.
(In reply to Matthias Andree from comment #4) > I don't see why we need to keep adding features such as PKG_DEPENDS if we > already have a working BUILD_DEPENDS. I find PKG_DEPENDS gratuitous. > > pkg _is_ a build requisite the way the b.p.m is set up, so there is little > point in keeping it out of BUILD_DEPENDS. > > FETCH_DEPENDS and PATCH_DEPENDS are different stories because these pertain > to long-standing features of ports. However, PKG_DEPENDS has been shoehorned > in recently without visible reason (to me, for one). > > What problem is this "PKG_DEPENDS split out from BUILD_DEPENDS" trying to > solve that _waiving_ a _version_ requirement could not solve? Pointless discussion as it doesn't change anything. Portupgrade would still fail here. PKG_DEPENDS is needed for installing packages and creating packages. FETCH_DEPENDS can use packages... > > The version requirement is only there because pkg was inflicted on the world > before it was mature. This is to some extent unavoidable because only the > wide testing base will unveil all of its bugs. > > I'd say bitch about an old version and print blinky red warnings, but > otherwise stay out of the user's way and continue the build, and forget > about version enforcement. I think you have an invalid view that Pkg should be "complete". Pkg will never be complete, nor will ports. We will continue to add new features to it. As we add new plist features it will require having a minimum Pkg version for those ports that use that feature.
I said this in the CR as well: >>! In D927#14, @mandree wrote: > As mentioned in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193844#c4 I propose to waive the version check, or make it non-fatal. There is no good reason NOT listing pkg as a build requisite. Warn all you want, but don't get in the user's way. There is a lot of pain involved for trying to solve a temporary problem (people having outdated pkg version) on the ports end. Let alone the expensive running of pkg all over the map just to inquire about its version. Useless complexity for little good. You clearly don't understand the point. Removing the version check would break ports and give us no path forward for ever adding new features. We added the version check exactly to address POLA problems with people running pkg-1.1 and 1.2 still and not being able to handle the manifest format. 1.3.8 introduced @dir which older versions could not handle. Even if we released a pkg with @dir and waited a YEAR before using it in a single port, we would have people finding they can't build ports before of "unknown keyword @dir". So we have a minimum check that is more clear immediately that they must upgrade. Really, we have people running pkg-1.1 and 1.0 still and sending in reports that caused us to add the minimum version check.
PKG_DEPENDS has been explained lots of time in the past there are reason which are totally tight to how the ports work for more than 10 years to be. Among all the reasons there is the order the targets are executed, and the *_DEPENDS are managed, the fact that pkg always needs to be the first in the dependency line when building, etc, this is all due to how the ports works nothing more Just digging a bit into the infrastructure will show it to you and you will see why it is impossible to add pkg into BUILD_DEPENDS without breaking very hard things.
The original two sins were: 1. to inflict pkg on the world outside of any base system cadence (schedule), and now we even advance to force people to upgrade pkg out of cadence. 2. to add and force features on users in patchlevel releases (I should have written "force", on Phabricator, too) We must not do that to our users. We must accept that users may have other goals than to keep running after the ports@ fad of the day. I myself am considering tossing in the towel on ports@ because following all the pkg madness in ports to stay on top of things is taking so much time I haven't nontrivial work on any other project since this stage stuff started. Other people have already quit, and I think more may follow, but that's just invoking a fallacy, so disregard this half-sentence. We exerted co"workers" (ports maintainers and committers) with this stage stuff that offered immediately-palpable value. And now we're doing gratuitous changes like @dir which is a minor syntax detail over @dirrmtry. We could easily offer this, and translate it to @dirrm and @exec mkdir for a few months, perhaps even conditionally on pkg version. And force people to upgrade to some pkg minor version in line with FreeBSD releases or end-of-life dates. Now we're rushing and forcing and bullying people and getting in their way. This isn't fun, it's an enormous amount of work for little and invisible good. We're forcing people away from certain pkg-plist syntax and make them move the interesting stuff into pkg-install. We're not getting any more control unless we take pkg-[de]install scripts away, but we're forcing people to change pkg-plist and Makefiles all the time for little good.