makeinfo if no native makeinfo executable exists. Honor TEXINFO_REQD
when determining whether the native makeinfo can be used.
* Remove USE_MAKEINFO and replace it with USE_TOOLS+=makeinfo.
* Get rid of all the "split" argument deduction for makeinfo since
the PLIST module already handles varying numbers of split info files
correctly.
NOTE: Platforms that have "makeinfo" in the base system should check
that the makeinfo entries of pkgsrc/mk/tools.${OPSYS}.mk are
correct.
backslashes anymore. A single backslash is enough. Changed the
definition in all affected packages. For those that are not caught, an
additional check is placed into bsd.pkginstall.mk.
around at either build-time or at run-time is:
USE_TOOLS+= perl # build-time
USE_TOOLS+= perl:run # run-time
Also remove some places where perl5/buildlink3.mk was being included
by a package Makefile, but all that the package wanted was the Perl
executable.
And always is defined as share/examples/rc.d
which was the default before.
This rc.d scripts are not automatically added to PLISTs now also.
So add to each corresponding PLIST as required.
This was discussed on tech-pkg in late January and late April.
Todo: remove the RCD_SCRIPTS_EXAMPLEDIR uses in MESSAGES and elsewhere
and remove the RCD_SCRIPTS_EXAMPLEDIR itself.
under share/examples/rc.d. The variable name already was named
RCD_SCRIPTS_EXAMPLEDIR.
This is from ideas from Greg Woods and others.
Also bumped PKGREVISION for all packages using RCD_SCRIPTS mechanism
(as requested by wiz).
under ${PREFIX} instead of being an absolute path.
So fix the references using RCD_SCRIPTS_EXAMPLEDIR to be
${PREFIX}/${RCD_SCRIPTS_EXAMPLEDIR}.
This should have no changes to use before.
Please note that the MESSAGE files in most cases are wrong in the
first place. We have automated mechanisms and could have an automated
message for explaining rc.d script usage. (This is something to do!)
in the process. (More information on tech-pkg.)
Bump PKGREVISION and BUILDLINK_DEPENDS of all packages using libtool and
installing .la files.
Bump PKGREVISION (only) of all packages depending directly on the above
via a buildlink3 include.
All library names listed by *.la files no longer need to be listed
in the PLIST, e.g., instead of:
lib/libfoo.a
lib/libfoo.la
lib/libfoo.so
lib/libfoo.so.0
lib/libfoo.so.0.1
one simply needs:
lib/libfoo.la
and bsd.pkg.mk will automatically ensure that the additional library
names are listed in the installed package +CONTENTS file.
Also make LIBTOOLIZE_PLIST default to "yes".
which installs to ${RCD_SCRIPTS_EXAMPLEDIR}. But the MESSAGE
referred to wrong hard-coded location if the RCD_SCRIPTS_EXAMPLEDIR
was not the default. So use RCD_SCRIPTS_EXAMPLEDIR instead.
PKGREVISION not bumped because if someone had changed
RCD_SCRIPTS_EXAMPLEDIR before recent change of autoregistration
of rc.d script in PLIST, then it could not have been packaged
in first place.
Note that this commit does not imply that the MESSAGE is correct.
In some cases, the MESSAGE is clearly wrong such as suggesting
running the rc.d script from the example directory (which will work
although).
the RCD_SCRIPTS rc.d script(s) to the PLIST.
This GENERATE_PLIST idea is part of Greg A. Woods'
PR #22954.
This helps when the RC_SCRIPTS are installed to
a different ${RCD_SCRIPTS_EXAMPLEDIR}. (Later,
the default RCD_SCRIPTS_EXAMPLEDIR will be changed
to be more clear that they are the examples.)
These patches also remove the etc/rc.d/ scripts from PLISTs
(of packages that use RCD_SCRIPTS). (This also removes
now unused references from openssh* makefiles. Note that
qmail package has not been changed yet.)
I have been doing automatic PLIST registration for RC_SCRIPTS
for over a year. Not all of these packages have been tested,
but many have been tested and used.
Somethings maybe to do:
- a few packages still manually install the rc.d scripts to
hard-coded etc/rc.d. These need to be fixed.
- maybe remove from mk/${OPSYS}.pkg.dist mtree specifications too.
USE_GCC2 or USE_GCC3 where appropriate.
the functionality of the old gcc.buildlink2.mk has been rolled into
compiler.mk now, which is automatically used.
more changes to come later...
Based on the sfs-0.6 package provided by Michael Santos in PR 18528.
SFS is a secure, global network file system with completely
decentralized control. SFS lets you access your files from anywhere
and share them with anyone, anywhere. Anyone can set up an SFS
server, and any user can access any server from any client. SFS
lets you share files across administrative realms without involving
administrators or certification authorities.
