Hi Mark,
> On Wed, Aug 17, 2011 at 04:36:23PM +0200, Julian H. Stacey wrote:
> > Better to leave the port marked as having some run errors in some
> > circumstances, that we dont have manpower for, but leave port in
> > tree.
>
> Then we have the situation of a user spends the time to install it only
> to figure out it's obsolete, broken, junk. This is not desirable.
>
> > At least it compiles. If removed, some people who look for such a
> > tool might not know it exists & is already ported.
>
> But doesn't work. As for contacting:
>
> > Jeremy Chadwick <koi...@freebsd.org>
>
> no longer involved with the project (since 2008).
>
> > David W. Chapman Jr. (dw...@freebsd.org)
>
> no longer involved with the project (since 2001).
>
> While FreeBSD can't make the statement "all ports in our Ports Collection
> are useful and secure", we can at least make the attempt to weed out
> obviously obsolete and/or broken and/or abandoned ports, so that prospective
> users of them don't waste their time.
> That's what this whole deprecation and cleanup work is for: to get rid of
> the bitrot.
I can live with whatever Chris, you & ports team decide on this port, But ..
I'd question _why_ valuable people like you & Chris would allow
your time to be distracted merely to try to get repair run time
capability of a port. Run time performance should be beyond priority
remit of central ports team, There's more important work for their
rare skills.
As Vadim Goncharov just wrote to arch@ Wed, 17 Aug 2011 23:10:19 +0000 (UTC)
on another thread:
"we often have not enough \n time/resources"
Only a limited number of people are skilled in ports/ variables &
arcane macros etc, many shy away. A great deal more normal *Unix*
generic people are perfectly capable of fixing many normal post
build problems, eg the run time problems of this port.
Ports team members with rare understanding of arcane ports make
variables & macros, should be concentrating on that, to enhance the
general automatic build capability, so less ports fight with each
other & break at build time.
Colliding & breaking ports has been The most serious problem of
ports for years. far more serious than bit rot in odd old obscure
ports, eg run time errors.
So, after repeating
I can live with whatever Chris, you & ports team decide on this port,
I'd suggest ports team spend minimal time on this port & other
similar bit rot ports.
Don't try to fix run time performance/errors.
Don't lose time on merit or de-merit of deleting a port that builds,
to allow 2 send-pr to be deleted.
Instead invent & apply new variable[s] eg
INSTALL_OR_RUN_DEPRECATED="summary of 2 send-prs"
aka eg
RUN_DEPENDS
BUILD_DEPENDS
etc
Consider that sufficient to allow a closure of send-pr after copying
send-prs to a README dir in the port. Leave it & other easy ports
runtime problems for less [ports]skilled users to fix. & conserve
your valuable time for the hard stuff, eg More compatability automation
between competing ports.
Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
Reply below, not above; Indent with "> "; Cumulative like a play script.
Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable.
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
