- use ?= for the portrevision of a master port to make it possible to
change it in a slave port which depends upon lame
- bump portrevisions of ports which depend upon lame
- done via a semi-automated way (manual review and fixup)
- I tried to take care to not bump ports which only depend optionaly on
lame (with a default of no dependency)
-Update libtool and libltdl to 2.2.6a.
-Remove devel/libtool15 and devel/libltdl15.
-Fix ports build with libtool22/libltdl22.
-Bump ports that depend on libltdl22 due to shared library version change.
-Explain what to do update in the UPDATING.
It has been tested with GNOME2, XFCE4, KDE3, KDE4 and other many wm/desktop
and applications in the runtime.
With help: marcus and kwm
Pointyhat-exp: a few times by pav
Tested by: pgollucci, "Romain Tartière" <romain@blogreen.org>, and
a few MarcusCom CVS users. Also, I might have missed a few.
Repocopy by: marcus
Approved by: portmgr
in bsd.autotools.mk essentially makes this a no-op given that all the
old variables set a USE_AUTOTOOLS_COMPAT variable, which is parsed in
exactly the same way as USE_AUTOTOOLS itself.
Moreover, USE_AUTOTOOLS has already been extensively tested by the GNOME
team -- all GNOME 2.12.x ports use it.
Preliminary documentation can be found at:
http://people.FreeBSD.org/~ade/autotools.txt
which is in the process of being SGMLized before introduction into the
Porters Handbook.
Light blue touch-paper. Run.
packages, so mark the port as NO_PACKAGE for patent licensing
reasons.
The distfile is safe to distribute.
Discussed with: trevor, Gabriel Bouvigne <bouvigne@mp3-tech.org>
Begin autotools sanitization sequence by requiring ports to explicitly
specify which version of {libtool,autoconf,automake} they need, erasing
the concept of a "system default".
For ports-in-waiting:
USE_LIBTOOL=YES -> USE_LIBTOOL_VER=13
USE_AUTOCONF=YES -> USE_AUTOCONF_VER=213
USE_AUTOMAKE=YES -> USE_AUTOMAKE_VER=14
Ports attempting to use the old style system after June 1st 2004 will be
sorely disappointed.
- take over maintainership (after some months of maintainer timeout)
Note: I have write access to the LAME repository, I think this is enough
to justify this and the following decisions.
- remove gtk support (it's only useful for active mp3 algorithm developers,
and if you use it, you use the CVS version of it, so there's no need to
install it)
- don't add vorbis support from PR 39606:
* there are much better tools to encode ogg vorbis
* there's no support from the LAME developers (FreeBSD would be the
only OS with working vorbis in LAME)
* it will get removed in a later LAME version
Submitted by: many, see PRs
PR: 39606, 43255, 43727
due to uncertainty: there are too many unsharable global variables.
Pointed out by Alexander Leidinger.
2) Due the last, revert to previous state without static library
installation
3) Revert patch template to patch-aa revision 1.7
4) Unique change that is not reverse related: update MASTER_SITES
using MASTER_SITE_SOURCEFORGE (joseph@randomnetworks.com)
5) PORTREVISION bump.
I am reverting this for I won't be around to discuss this for the
time being. :)
If anyone wants to, please contact the submitter.
Submitted by: Alexander Leidinger <Alexander@leidinger.net>,
Joseph Scott <joseph@randomnetworks.com>
