Date: Mon, 15 Aug 2011 03:23:55 +0400 From: Dmitry Marakasov <amdmi3@amdmi3.ru> To: Peter Jeremy <peterjeremy@acm.org> Cc: cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: cvs commit: ports/cad/admesh Makefile Message-ID: <20110814232355.GE38385@hades.panopticon> In-Reply-To: <20110814220027.GA29836@server.vk2pj.dyndns.org> References: <20110811180338.GB88978@hades.panopticon> <CADLo839VotWbi209%2BeR3LAuQ4HqC-LSGY4avcUFXHat=HjsrKg@mail.gmail.com> <20110812093328.GE85247@hades.panopticon> <b0535f6d53bb546b54d85797ec66cf0b@etoilebsd.net> <20110812101133.GF85247@hades.panopticon> <4E4584EA.7090306@FreeBSD.org> <20110813133717.GA38385@hades.panopticon> <4E469837.1030903@FreeBSD.org> <20110813172040.GC38385@hades.panopticon> <20110814220027.GA29836@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Peter Jeremy (peterjeremy@acm.org) wrote:
> 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.
That is true for all ports. Maintained ones are not a tiny bit
better/different in this perspective.
> > 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.
Unfortunately, even if there is a maintainer, it's as unlikely that
vulnerabilities will be reported - you may subscribe any vuln list
(or just read some IT news) and compare it to vuxml changes if you
don't believe. However, portaudit IS the mechanism that is designed
and that should be used for security stuff, while "ports being up
to date and/or maintained" is absolutely not - it would be a mistake
to rely on it, and there is no link between these two properties
at all.
Security is out of scope of this thread, however I think it should
not depend on maintainers (cause it simply doesn't work this way)
and it may and should work automatically, as CVE and other sources
are quite friendly to automatic parsing.
> 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.
You can't do this, as a port without maintainer doesn't mean it's
unmaintained, as well as a port with maintainer doesn't mean it's
maintained. To be able to rely on MAINTAINER, you need completely
different set of rules, different community organization and much
more capable set of publicly accessible tools - where a problem in
(for example) unmaintained /cad port will/may go to (at least!)
cad@ (which can decide if a port is not needed any more and/or fix
it), security (which would apply security patches), some people
which use it but not obliged to fix anything, however being interested
in the port to continue working ("consultants").
Until we have something like that, you can't count on maintainer
at all, you can't assume that unmaintained port doesn't have a
maintainer and you can't decide for any "unmaintained" port given
it builds and works.
> >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.
Committers are completely unrelated.
> > 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.
Seems redundant for me. Repeated: it IS fetchable, and as it's been
told (not by me) the problem is not in being (un)fetchable.
> > "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.
Well, I've been told on this thread that `the community decided' -
perhaps these are "FreeBSD guys" I don't feel like associating
myself with. Anyway, as a FreeBSD guy I'm trying to solve the
problem, which is none except for a person(s) who decided that some
working ports (some even with dependencies) may be just marked
BROKEN for everyone's sake. If you consider that correct, I'd like
to hear your version of a correct answer to the user.
> >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.
Sure. Afaik, a synopsis of that had been already posted to some of
our maillists.
> >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.
Agreed, that'd be even more informative and closer to BROKEN
semantics.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110814232355.GE38385>