On 2025-02-11 12:32, Yusuf Yaman wrote:
Sorry but I didn't understand what you are trying to do properly but is
it an option to make a port for every dependency?
Composer-managed dependencies are, to use compiler parlance,
static-linked when the main application is compiled. Assuming they're
even available as ports, I would still need to copy the code into the
vendor subdirectory and generate the linking code so the main
application requires (PHP for include) them at run-time. IOW, port or
no, I would still need to use Composer to actually install them. Since
Composer won't leverage installed ports (it fetches everything from
Github directly), moving the dependencies into ports is moot.
Thank you for thinking through this and offering alternatives. These
are ideas I've worked through previously, and it's nice to be able to
revisit them and reiterate my understanding for someone else.
Basically I have two options:
1. Leave the Composer run as a step for the user to complete. This is
the expected process, but it means what they end up installing is
potentially something I've haven't test because when they run Composer
it can select a newer version than what I tested, and now I, the lowly
port maintainer, am stuck with someone emailing me about their port not
working when the fix will ultimately mean changing some JSON over which
I may have no control (6 of the 10 dependencies are indirect dependencies).
2. I can do the Composer run myself, then provided the result as a
bundle to go with the port. This lets me deliver the port with the
dependecies tested and locked for that PORTVERSION/PKGVERSION. It means
I can provide the necessary QA for what the user will end up installing
and am in a better position to provide support.
The first option is less work up front and avoids licensing questions,
but leaves me with an unknown future support problem. The second option
is more work up front, and requires I handle things like licensing
administrivia, but makes the port more reliable/supportable.
On 2/11/25 23:20, [email protected] wrote:
On 2025-02-11 11:48, Yusuf Yaman wrote:
Can you see Porter's Handbook 5.8.7 LICENSE_DISTFILES and
LICENSE_DISTFILES_NAME.
If you have multiple distribution files, then this maybe work for you.
Example 38. LICENSE_DISTFILES
Used when the distribution files do not all have the same license. For
example, one has a code
license, and another has some artwork that cannot be redistributed:
MASTER_SITES= SF/some-game
DISTFILES= ${DISTNAME}${EXTRACT_SUFX} artwork.zip
LICENSE= BSD3CLAUSE ARTWORK
LICENSE_COMB= dual
LICENSE_NAME_ARTWORK= The game artwork license
LICENSE_TEXT_ARTWORK= The README says that the files cannot be
redistributed
LICENSE_PERMS_ARTWORK= pkg-mirror pkg-sell auto-accept
LICENSE_DISTFILES_BSD3CLAUSE= ${DISTNAME}${EXTRACT_SUFX}
LICENSE_DISTFILES_ARTWORK= artwork.zip
That won't work in this case, because it's not the port that fetches the
dependencies, but Composer. The port fetches two distfiles:
- the main application distfile
- a tarball containing the other distributions
I make the second distfile by running `composer install` myself then
tarballing the vendor subdirectory. All four licenses apply to its
contents.
