- is unmaintained/outdated for years
- has a lot of PLISTed files that change during usage
- @comment no checksum or @sample don't help here
suggested by and ok aja@, ok sthen@
instead. It is just too hard to maintain a coherent list of still
reachable homepages for GNOME projects so use wiki.gnome.org which is
the entry point for *all* GNOME apps.
- ezpublish, no maintainer, last updated 2009/08/24
- mantis, no maintainer, out of date
- phplist, very outdated and no-one maintains it
- phpmemcachedadmin, port only extract the distfile and that's it
- vtigercrm, port only extract the distfile and that's it
While we do this in a case-by-case basis, this was done for one of the
following reasons:
* do not give user a sense of security because there is a pkg available
when it is in fact outdated/unmaintained and including possible security
issues
* package with no added value besides extracting the distfile under
/var/www are pretty useless -- they demand an effort to be kept up to
date for no benefits (except if someone actually maintains it of course)
* some webapps must complete a strict version update path -- eg.
updating from 1.0 to 1.5 requires updating to 1.1, 1.2, 1.3 and 1.4
first -- that does not work well with pkg
ok Wen Heping (MAINTAINER of vtigercrm)
ok sthen@ jasper@ robert@
PS: no we are not in a rampage to remove lots of www apps -- just some when
it makes sense
just a matter of following upstream and untarring under htdocs.
webapp as a pkg needs to have some added value and no, 'pkg_add webapp' is
not easier if the app has actually no maintainer -- it is safer to follow
upstream.
webacula is one of them and is not even maintained upstream, so zap it.
discusssed with and ok sthen@
just a matter of following upstream and untarring under htdocs.
webapp as a pkg needs to have some added value and no, 'pkg_add webapp' is
not easier if the app has actually no maintainer -- it is safer to follow
upstream.
photoshow is one of them and is not even maintained upstream, so zap it.
discusssed with and ok sthen@
The port isn't maintained and rather out-of-date, it doesn't add much
value by way of easy installation instructions, and additionally if we
were to update to a current version, the upgrade procedure requires
going through an intermediate version. As such, users are advised to
install through standard distfiles instead.
You served us well but you're EOL'ed upstream since 17 months, and your
only reason d'etre was sparc64, but those days www/mozilla-firefox works
there.
Users will be upgraded for free to www/mozilla-firefox !
(note: not cvs rm'ed yet, since devel/xulrunner still uses the patches..)
- see http://www.seamonkey-project.org/releases/seamonkey2.21/
- fixes MFSA 2013-76 -> 92 (84, 86 & 87 didnt affect SM)
- remove BROKEN-sparc64 \o/
- add sparc64 & alpha (insane!) to MODGCC4_ARCHS
- remove patch-gfx_thebes_gfxPlatform_cpp, was merged upstream in
#722975 (and we dont build with system cairo anyway now)
- remove useless patch-parser_html_Makefile_in, maybe it made sense in
the gcc 3 / ffx 3.6 days but those are over...
- see http://www.mozilla.org/en-US/firefox/24.0/releasenotes/
- fixes MFSA 2013-76 -> 92
- remove BROKEN-sparc64, it now works thanks the awesome work of
martin@netbsd.org in bugs #871101 & #871555 among others i forgot
- add sparc64 & alpha (insane!) to MODGCC4_ARCHS
- remove patch-gfx_thebes_gfxPlatform_cpp, was merged upstream in
#722975 (and we dont build with system cairo anyway now)
- remove useless patch-parser_html_Makefile_in, maybe it made sense in
the gcc 3 / ffx 3.6 days but those are over...
(note: a spellchecker issue since fx 23 is known, and might be fixed
later on)
- stop building ff/tb/sm with systemwide cairo, it differs too much from
the bundled cairo and brings us too many issues (font weirdness,
crashes on i386 when links are dnd'ed, maybe system slowness when
displaying huge images, and others i dont remember..). Anyway, this is
not really "supported" upstream. To be revisited once mozilla updates to
cairo 1.12.x, if ever (#739096).
- move comment about system-jpeg, krb5 WANTLIB, and post-extract target
about sydneyaudio sndio backend when they belong (ie in the 'old' users
case).
