The i386-wine ports bundle their own (32-bit) libraries that cause pkg-1.5
issues. Since these libraries are under lib32 it does not cause issues
with other software.
Bump PORTREVISION [1] for the 32-bit side of the ports. The 64-bit side of
the ports will be bumped when new packages have been prepared.
Approved by: gerald@ [1]
Reported by: bapt@
Changes:
- Fix install conflicts [1] (for the "newly" added compholio port)
- nvidia.sh: Gracefully handle a corrupt nVidia tarball
- nvidia.sh: Provide checksum and size information for nVidia tarball
- Bump master port [1] due to changes to nvidia.sh and conflicts
Approved by: gerald@ [1]
With the removal of REINPLACE_PLIST in r367153 building wine on FreeBSD/i386
broke. This was not detected in an exp-run as i386-wine is marked IGNORE
unless WINE_CROSS_BUILD is defined (to protect the build infrastructure and
avoid confusion).
PR: 193734
Merge back bsd.pkgng.mk into bsd.port.mk
Add a note about @stopdaemon not being supported anymore
With hat: portmgr
Differential Revision: https://reviews.freebsd.org/D693
Due to the hackery things these ports do to properly work under amd64, it
results in issues for pkg. This port - although it needs to build under
i386 - is not intended to be consumed under i386. The normal wine(-devel)?
ports should be consumed on an i386 system and these ports should be
consumed on an amd64 system. [1]
Reorder the library detection to pick up soft dependencies first, then the
linked to libraries. Prior to this change any libraries required by a soft
dependency wasn't bundled, for example libgnutls.so.28 did not have its
dependencies bundled. [2][3]
Requested by: bdrewery [1]
Reported by: Joseph Mingrone <jrm@ftfl.ca> [2]
Beeblebrox <zaphod@berentweb.com> [3]
* Add support for a forthcoming i386-wine-compholio port [1]
* Fix binbounce for RPATH issues [1]
A port revision bump is not possible due to the complexities for the wine
ports. The impact is minimised by timing these updates closely with the
underlying updates of wine-devel.
Requested by: [1] Kris Moore <kris@pcbsd.org>
Reported by: [2] Nils Beyer <nbe@renzel.net>
Changes:
- Fix the patch-nvidia.sh script's usage of getopt [1]
- Fix the patching of the packages for installation on amd64 [2]
-
Reported by: [1] Nicole Reid <nicole@cooltrainer.org>
[2] Piotr Kubaj <pkubaj@riseup.net>
Port ChangeLog:
- Update to version 1.7.4 (for pre-built packages for amd64)
- Add stage support for both Makefile.(i386|inc)
- Add the -devel suffix and remove LATEST_LINK
- Teach the patch-nvidia.sh script about the -devel suffix
- Track updates for the GECKO version (2.24)
Correct version detection to complain when installing outside the
supported range (8.3+ and 9.1+).
Also, exclude ldconfig data from pkg-plist.
Reported by: Sergey V. Dyatko
The binary package for amd64 systems does not bundle GECKO or MONO
however it is useful (for some) to have those files installed, so
allow the package to have a run-time dependency on the ports that
provide Gecko and Mono support.
PORTREVISION is not bumped since nothing changes in the default
(BATCH) case.
CHANGES
-------
Provide two ports, in one. When compiling on i386 the port behaves
as a slave port of wine-devel, creating a package suitable for
installation on amd64. No change here
When compiling on amd64 the port manually installs the provided
amd64 packages (see wiki.FreeBSD.org/i386-Wine for those packages)
and thus allowing the packages to be "build" using the FreeBSD
infrastructure, and critically, to appear in the standard package
set without requiring users to manually add these packages to their
systems.
DESIGN
------
The bootstrapping (for choosing between i386 and amd64 Makefiles)
was done manually as Makefile.i386 is a slave port while Makefile.inc
(for amd64) is a master port. This situation does not work in the
current infrastructure thus requiring a manual bootstrap.
PRECEDENT
---------
Although Ports does not support cross compiling of packages there is
precedent in supplying binary packages for those situations where,
otherwise, cross compiling is required.
In support of taking this approach I site:
- misc/compat?x ports
- */linux-* ports
