plist.mk: Cheap fix for PLIST madness found with Issue #4211

[th0ma7]

Motivation: Fix PLIST black-magic issue found
Linked issues: #4211

Checklist

• Build rule all-supported completed successfully
• Package upgrade completed successfully
• New installation of package completed successfully

[th0ma7]

@hgy59 and @ymartin59 and all, here is a temporary fix proposal for the PLIST issue as documented in #4211.
Preliminary test shows that is works against fossil-scm.
Requires more testing...

[th0ma7]

Solution ain't sufficient, needs additional thinking or complete rewrite of the PLIST code.
This quick fix proposal doesn't handle per arch sub-dependencies which are then considered mandatory for all arches.
Complex package such as ffmpeg is a good one to test with.

[hgy59]

If you take dependency-list instead of $(DEPENDS) you get the dependencies of $(BUILD_DEPENDS) $(DEPENDS) $(OPTIONAL_DEPENDS)
but this will fail because all files in PLIST must exist (and the optional are dependencies that exist not for all archs).
And BUILD_DEPENDS is for packages that are used only in the build environment and not needed at runtime (i.e. dependency of another spk like python).
If dependency-list fixes the PLIST file for some packages, those packages may have used BUILD_DEPENDS but should have used DEPENDS.
As for fossil-scm if the error you meant in #4222 is missing PLIST files of openssl or zlib, then the real error is that fossil-scm has defined BUILD_DEPENDS instead of DEPENDS for cross/zlib and cross/openssl.

[hgy59]

Just used grep and found false usage of BUILD_DEPENDS in

• cross/autossh
• cross/he853
• cross/tcl
• spk/borgbackup
• spk/duplicity
• spk/ffsync
• spk/mercurial

[th0ma7]

Just used grep and found false usage of BUILD_DEPENDS in

How do you do to you determine if theses are false usages of BUILD_DEPENDS ?

[hgy59]

Just used grep and found false usage of BUILD_DEPENDS in

How do you do to you determine if theses are false usages of BUILD_DEPENDS ?

if a package has BUILD_DEPENDS on it's own it must fail, as it is not (properly) packaged into the spk.

• may be I am wrong here (cross/duplicity and cross/borgbackup are wheels)

cross/tcl:

• this package links to zlib (I cannot see any options that zlib is statically linked), and must define DEPENDS = cross/zlib

cross/autossh:

• this package links to openssh and must define DEPENDS = cross/openssh

cross/he853:

• this package links to cross/libusb and must define DEPENDS = cross/libusb

spk/ffsync:

• here I am not sure, as cross/gevent cross/greenlet may be used for building wheels only. But I guess these two libraries are needed at runtime and not only at build time.

spk/mercurial:

• another wheel package, where I don't know whether the wheel includes all the dependencies or not.

So my statement was hasty - not regarding the dependencies of wheels - but for non python wheels following packages must use DEPENDS instead of BUILD_DEPENDS:

• cross/autossh
• cross/he853
• cross/tcl

and

• cross/fossil-scm

[ymartin59]

I am curious to know what "code changes" has introduced bug to better understand how to get it fixed. Does it come from moving targets to dedicated "plist.mk" file?

[th0ma7]

I am curious to know what "code changes" has introduced bug to better understand how to get it fixed. Does it come from moving targets to dedicated "plist.mk" file?

There was no code change from the framework point of view. Also the changes I recently did had no effect on the PLIST part of the framework.

If there was a change it may end-up being in a dependency being build only with shared libs or a change in configuration option that make a binary to not link against the expected static lib but rather needing the shared lib instead.

Thus, from @hgy59 analysis and comment above, some of the packages must use DEPENDS instead of BUILD_DEPENDS. No one yet took action AFAIK on that. Part of the proposed list figures also fossil-scm, package which me starting this whole thread originating from #4211 (comment) and proposed approach in this "tentative" PR.

Lastly, note that code in this PR is irrelevant (thnx to @hgy59)... although discussions may lead at finding a better approach.

[hgy59]

I am curious to know what "code changes" has introduced bug to better understand how to get it fixed. Does it come from moving targets to dedicated "plist.mk" file?

The code change for fossil was with commit 26ad900 on cross/fossil-scm/Makefile
26ad900#diff-8a946aa031b07b52cf3ae47688cfe3536e3dba5ad14d011e6fa45c4c0c4659e4

by removing --static from CONFIGURE_ARGS without changing BUILD_DEPENDS to DEPENDS.

[ymartin59]

As a local mistake in fossil-scm I propose to close without merge

[th0ma7]

Agreed.
@hgy59 Before closing, is there any action left to do considering your previous comment #4221 (comment) ? Should another issue be opened to track it?

[hgy59]

Agreed.
@hgy59 Before closing, is there any action left to do considering your previous comment #4221 (comment) ? Should another issue be opened to track it?

@th0ma7 PR #4257 created