cvs commit: ports/cad/admesh Makefile

[Peter Jeremy]

On 2011-Aug-13 21:20:40 +0400, Dmitry Marakasov <amdmi3 at amdmi3.ru> wrote:
>You can't judge the quality of software by "it is maintained" or
>"it is the latest version" either, actually there is no corellation
>at all.

There is very little bug-free software available.  And even if you
manage to find a piece of software that is bug-free, changes to its
dependencies can introduce problems as interfaces change.

> For the security, we have portaudit.

I can only assume this statement is a joke.  The vulnerability list
that portaudit relies on in manually maintained - it's generally up to
port maintainers to update this list.  If there isn't a maintainer,
it's unlikely that vulnerabilities will be reported.

>> Possibly we should always mark ports for removal for three months after
>> the point in time when the maintainer gets reset to ports at .

Three months might be a bit soon but I think it would be a good idea
for the ports build infrastructure to warn about unmaintained ports -
eg building/installing it gives a message "warning: this port is
unmaintained, it may not be up-to-date and may include unreported
vulnerabilities" as well as an "unmaintained packages you have
installed" report in periodic/weekly.  With the current system, it's
not obvious that pors are unmaintained.

>Nice. Well that'll only result in two processes: more and more ports
>will have maintainers reset and then removed, and remaining maintainers
>will take more and more ports beyond their ability to maintain them,
>both will lead to collapse. Is this also not undesirable?

As you would be aware, committers != maintainers.  And it's difficult
to see how fewer ports translates to more load on the committers.

> And now I wonder what should I say
>if a user asks why $port he wants doesn't build becase $dependent_port
>is marked 'does not fetch' even after he downloaded the distfile
>on his own?

Maybe there needs to be an "UNFETCHABLE" variable that expands to
"BROKEN=unfetchable" unless the distfile is already present.

> "FreeBSD guys don't want you to use this ports, sorry, go
>away or fix it". That is what I call a nice attitude.

And that's not what is meant.  If that's the way you are responding
to such questions, it is not really helping.  Note that you are
one of the "FreeBSD guys" that you disparage.

>Also there had been a huge article an a discussion thread on "Key
>FreeBSD problems and a way to solve them" after Rambler and Yandex
>(largest FreeBSD using companies in Russia) decided to switch from
>FreeBSD to Linux, which also mentions port problems and, which is
>much worse, an attitude like yours. Let me translate an excerpt:

Your excerpt does not mention ports and raises issues that are far
more wide ranging.  It needs to be discussed separately in a more
appropriate forum.

>A bit of constructive. While writing this I've got an idea: why
>don't we introduce DEAD variable for this case?

Yes.  That sounds like a worthwhile idea.  I'd suggest "DEAD" take
a string that is presented to the user, rather than just producing
a generic list of possibilities:

===>  foo-1.0 is marked as dead: No master site found
You may still build this port on your own rish by adding TRYDEAD=yes
to make arguments or enironement. Note that dead port will be
eventually removed from the ports tree if nobody steps forward to
become its maintainer and/or fix it.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-ports/attachments/20110815/9cad4c13/attachment-0001.pgp