UNIQUENAME was never unique, it was only used by USE_LDCONFIG and now,
we won't have conflicts there.
Use PKGBASE instead of LATEST_LINK in PKGLATESTFILE, the *only* consumer
is pkg-devel, and it works just fine without LATEST_LINK as pkg-devel
has the correct PKGNAME anyway.
Now that UNIQUENAME is gone, OPTIONSFILE is too. (it's been called
OPTIONS_FILE now.)
Reviewed by: antoine, bapt
Exp-run by: antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D3336
The targets now have priority assigned to them, and, when the dependency
ordering magic is done at the end of bsd.port.mk, they are sorted
according to their priority.
This allows USES to add targets easily and have them run whenever they
want without touching bsd.port.mk.
To add a target that runs just before post-configure run, do:
_USES_configure+= 695:my-post-configure
my-post-configure:
do something
To fine tune when the target is ran, look at the values in the *_SEQ
variables at the end of bsd.port.mk, and the other USES.
Allow ports Makefiles to override the priority of targets with the
TARGET_ORDER_OVERRIDE variable. For example, to get post-install
running earlier, (its default is 700) do:
TARGET_ORDER_OVERRIDE= 650:post-install
While there, add options target helpers for the do-* targets when they
exist.
Reviewed by: antoine, bapt
Exp-run by: antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D3099
64 bit linuxulator support (not activated by default):
- most of the work was done by Alan Jude
- all errors are mine
- 64bit (may) have rough edges
- I validated
* that the 32bit part doesn't has deinstall regressions (incl. EXP runs by
antoine)
* 29 of 72 64bit ports ports don't have deinstall leftovers (more validation
later, when I dare to activate the 64bit linuxulator in the kernel)
- the infrastructure part looks mature enough to let more test-bunnies get
some experience with the new 64 bit parts
- to use it you shall have no linux ports installed and have to specify
(on your own risk) the following in make.conf before installing the ports:
OVERRIDE_LINUX_BASE_PORT=c6_64
OVERRIDE_LINUX_NONBASE_PORTS=c6_64
This is on top of the exiting c6 linux ports. Given that CentOS 7 is 64bits
only, we decided to have it as an "overlay" instead of new ports.
The 64bit part only installs 64bit executables, the 32bit ports can not be
installed at the same time (if needed we can think of letting the 64bit
overlay install the 32bit parts too, but given the CentOS 7 comment
above...).
Differential Revision: https://reviews.freebsd.org/D174
Submitted by: alanjude
Sponsored by: Essen FreeBSD Hackathon 2015
Reviewed by: xmj, eadler (earlier versions)
Approved by: portmgr (antoine after some EXP-runs)
- most of the work was done by Alan Jude
- all errors are mine
- 64bit (may) have rough edges
- I validated
* that the 32bit part doesn't has deinstall regressions
* 29 of 72 64bit ports ports don't have deinstall leftovers (more validation
later, when I dare to activate the 64bit linuxulator in the kernel)
- the infrastructure part looks mature enough to let more test-bunnies get
some experience with it
- to use it you shall have no linux ports installed and have to specify
(on your own risk) the following in make.conf before installing the ports:
OVERRIDE_LINUX_BASE_PORT=c6_64
OVERRIDE_LINUX_NONBASE_PORTS=c6_64
This is on top of the exiting c6 linux ports. Given that CentOS 7 is 64bits
only, we decided to have it as an "overlay" instead of new ports.
The 64bit part only installs 64bit executables, the 32bit ports can not be
installed at the same time (if needed we can think of letting the 64bit
overlay install the 32bit parts too, but given the CentOS 7 comment
above...).
Differential Revision: https://reviews.freebsd.org/D174
Submitted by: alanjude
Sponsored by: Essen FreeBSD Hackathon 2015
Reviewed by: xmj, eadler (earlier versions)
Approved by: portmgr (implicit, I remember blanked approval for
linux parts loooong ago, punish me if you don't
agree anymore)
Move inlined shell code into a proper script taking 2 args in arguments: full or
limited. The code I more simpler and understandable. The argument allows to
factorize the code between CLEAN-DEPENDS-FULL and CLEAN-DEPENDS-LIST
While here, make the code accept dependencies without ${PORTSDIR}
No cdrom distfiles has been shipped for a while, and it causes issues
for users having /cdrom configured in autofs
Reported by: glebius
Tested by: glebius
Approved by: swills
Reviewed by: swills
Differential Revision: https://reviews.freebsd.org/D2888
The benefice beside being more readable is to allow support for dependency line
without ${PORTSDIR}
This is also necessary to be able to easily hack on it for FLAVORS/SUBPACKAGE
support
This is an important step to prepare the ports tree for VARIANTS(aka flavours)
and subpackage by making the dependency code easier to deal with.
Change:
- Externalize in a proper shell script the code that was an inlined shell script
- Add better validation on the syntaxe used
- test after the dependency has been installed that it actually really fulfill
the pattern searched (improving QA)
- Unify lib-depends with other dependency checks
- Make ${PORTSDIR} not mandatory anymore in _DEPENDS lines:
aka pattern:${PORTSDIR}/category/port can now be written pattern:category/port
/!\ Please to not use this syntax yet! poudriere have received a fix to be
able to handle this new syntax (but no new release of poudriere has it yet)
portmaster/portupgrade hasn't been checked. if one cares about those last 2 it
would be really nice to provide patches to them!
- Remove _DEPENDS_ALWAYS it has half broken for a while and did not really make
sense.
- Keep STRICT_DEPENDS for now it might not be necessary anymore given all the
new checks added, but until someone confirms it is worth keeping it.
Note that all the env passed are prefixed by 'dp_' to avoid polluting children
make
Differential Revision: https://reviews.freebsd.org/D2897
Reviewed by: antoine
Exp-run by: antoine
package as a regular user
USES=fakeroot and USES=uidfix does a better job and is less intrusive and allows
to simplify the way we handle the different targets in the framework
Examples of use:
* BROKEN_FreeBSD= does not link
* BROKEN_DragonFly= requires later jail
* BROKEN_FreeBSD_8= long type-name is invalid
The latter example could replace something like:
.include <bsd.port.pre.mk>
.if ${OPSYS} == FreeBSD && ${OSVERSION} <= 900000
BROKEN= long type-name is invalid
.endif
Differential Revision: https://reviews.freebsd.org/D2207
Reviewed by: portmgr
Approved by: portmgr (mat)
similar to MASTER_SITES/PATCH_SITES.
Some helpful variables are provided: WRKSRC_<group> for putting things in the
right place in post-extract, and DISTNAME_<group>/DISTFILE_<group> for use with
EXTRACT_ONLY.
PR: 200483
Differential Revision: https://reviews.freebsd.org/D2608
Submitted by: mat
With hat: portmgr
Exp run by: antoine
Sponsored by: Absolight
The GH_TAGNAME-based GH_TAGNAME_EXTRACT is now always used for the new style
USE_GITHUB WRKSRC default.
This was not spotted before since all but 1 github ports were using 'v' as a
prefix, where github already stripped it. So the default GH_PROJECT-DISTVERSION
was fine. The other case was x11-fonts/sourcesanspro-ttf where
GH_TAGNAME was defined to have the full DISTVERSION prefix/suffx.
Tested against all current USE_GITHUB !GH_COMMIT ports.
PR: 199913
With hat: portmgr
Reported by: jbeich
When using GH_TAGNAME the DISTNAME would have GH_PROJECT and GH_ACCOUNT in
it. When not using GH_TAGNAME it would not have this. Now both cases
will add in the GH_PROJECT and GH_ACCOUNT.
Add special care to ensure that the DISTVERSION is not added in twice. If
a port does GH_TAGNAME=v${PORTVERSION} it will be added in twice though. For
that case DISTVERSIONPREFIX=v should be set and no GH_TAGNAME should be used.
empty() is used rather than (!defined || !${}) to support fmake.
The purpose of setting DISTNAME at all in these cases is to make it more clear
that the distfile is from *GITHUB* and to avoid collisions if a project were
to be renamed or moved. Without adding in GH_PROJECT and GH_ACCOUNT then there
are real risks that collisions on filenames would happen on renamed or moved
projects, which is fairly common. A GITHUB-generated file may not match
a custom-rolled or git-archive-rolled distfile.
PR: 199069
With hat: portmgr
Testing done: All USE_GITHUB ports without GH_COMMIT were checksum/fetch/extract/WRKSRC tested.
not install missing ones, and considers any missing ones as fatal.
This will be used by Poudriere to validate dependency lines are correct.
An example case is:
RUN_DEPENDS= foo:${PORTSDIR}/ports-mgmt/bar where the port does not provide
anything named 'foo'. In every phase it will attempt to install the bar port
to satisfy the depdendency and continue to fail to satisfy it. This can
eventually lead to unexpected errors such as trying to install a port
in the 'stage' phase when running as non-root and will encounter a pkg(8)
permissions issue.
This sort of issue occurred in http://lists.freebsd.org/pipermail/freebsd-ports/2015-April/098892.html
Discussed with: bapt
With hat: portmgr
- Add --localstatedir=/var to _LATE_CONFIGURE_ARGS (like --mandir) but not
when CONFIGURE_ARGS already sets it. (GNU configure scripts set it to
PREFIX/var when PREFIX != /usr.)
- Add --localstatedir="${PREFIX}/var" to CONFIGURE_ARGS in some ports so
they aren't affected by this change (for now at least). This commit is
meant to ensure that new ports don't make the same mistake.
- games/acm: the configure script in this port is very old; instead of
patching it more, just replace GNU_CONFIGURE with HAS_CONFIGURE.
- irc/charybdis: it already used /var but adding --localstatedir=/var
changed the behaviour of the configure script; adjust the port to this.
PR: 199506
Exp-run by: antoine
Approved by: portmgr (antoine)
if OSVERSION is specified on the cmdline. This makes testing simpler.
This only works for bmake.
# make -V CONFIGURE_LIBS
-lnew_release
# make -V CONFIGURE_LIBS OSVERSION=800000
-lolder_release
# env OSVERSION=800000 make -V CONFIGURE_LIBS
make: "/root/svn/ports/Mk/bsd.port.mk" line 1182: UNAME_r (11.0-CURRENT) and OSVERSION (800000) do not agree on major version number.
# echo OSVERSION=800000 >> /etc/make.conf
# make -V CONFIGURE_LIBS
make: "/root/svn/ports/Mk/bsd.port.mk" line 1182: UNAME_r (11.0-CURRENT) and OSVERSION (800000) do not agree on major version number.
Reported by: danfe
With hat: portmgr
