From owner-cvs-all@FreeBSD.ORG Sat Aug 13 17:20:44 2011 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B775F106566C; Sat, 13 Aug 2011 17:20:44 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [92.53.116.15]) by mx1.freebsd.org (Postfix) with ESMTP id 4161F8FC22; Sat, 13 Aug 2011 17:20:44 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1QsHyD-0001OW-SI; Sat, 13 Aug 2011 21:26:01 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 7E33CB865; Sat, 13 Aug 2011 21:20:40 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 66370B825; Sat, 13 Aug 2011 21:20:40 +0400 (MSD) Date: Sat, 13 Aug 2011 21:20:40 +0400 From: Dmitry Marakasov To: Matthias Andree Message-ID: <20110813172040.GC38385@hades.panopticon> References: <201108020942.p729g1Ti068765@repoman.freebsd.org> <20110811180338.GB88978@hades.panopticon> <20110812093328.GE85247@hades.panopticon> <20110812101133.GF85247@hades.panopticon> <4E4584EA.7090306@FreeBSD.org> <20110813133717.GA38385@hades.panopticon> <4E469837.1030903@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4E469837.1030903@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Baptiste Daroussin , Doug Barton , cvs-all@FreeBSD.org, ports-committers@FreeBSD.org, Chris Rees , cvs-ports@FreeBSD.org Subject: Re: cvs commit: ports/cad/admesh Makefile X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: **OBSOLETE** CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 17:20:44 -0000 * Matthias Andree (mandree@FreeBSD.org) wrote: > > Maybe we should stop doing things that raise such discussions then? > > No. Such poking the sleeping is necessary to get action taken at all. There should be a reason for taking action. There is none. > > "Dead" means it doesn't build or doesn't work. Which exactly of > > these "unfetchable" ports doesn't build or doesn't work? > > It's irrelevant. Unmaintained ports of any kind are a danger to the end > users. They might miss crucial (security or critical) patches, and you > can't judge the quality of software by "it builds and we mirrored an > obsolete version years ago". 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. For the security, we have portaudit. > Typically this situation arises if there are no users of a port left, > else the complaints come much earlier. Complaints come when there is a problem. But in this case there is no. You may create it for no reason though, which is a way to go. > And if there are no users, culling a port no matter whether your > local culture considers it "dead" is not a loss except that we > might some day fall below 20,000 ports. > Which is neither likely nor undesireable. :) > > That is strange definition of "dead". Does it stop being dead if I > > mirror distfiles? Have all dependent ports (on graphics/lib3ds, > > lang/expect, for example) suddenly became dead too? > > You offer an "upstream" package and become the contact for issues. Just > mirroring bit-rotten crap isn't going to help anyone. Unsupported > software is plainly and clearly a dead end, and I try to avoid running > in such dead ends whenever I can. You just can't decide for all users. > Possibly we should always mark ports for removal for three months after > the point in time when the maintainer gets reset to ports@. 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? > > What has happened is users being unable to build perfectly working > > ports because of unneeded BROKEN's. FreeBSD ports are criticized for > > frequent build problems, there are talks about stable port branch > > for user to experience less frustration with ports tree, yet such > > plain sabotage is happening. > > False. Users can set TRYBROKEN=yes and see how far they get. To know of TRYBROKEN, user should read either porter's handbook or bsd.port.mk source, as it is not mentioned in handbook or any manpage, while the user should't be required to read extra docs to install a working port at all. > False in that I don't see "FreeBSD ports that are criticized for > frequent build problems". Well, you should communicate with users more - then it becomes apparent. I dwell on a russian FreeBSD site bsdportal.ru and see ports problems quite often. 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? "FreeBSD guys don't want you to use this ports, sorry, go away or fix it". That is what I call a nice attitude. 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: " Social problem of FreeBSD comminity is disregard to needs of plain users, which do not belong to the community core. Developers tend to write the system "for themselves" e.g. for those who will use it despite the inconveniences, and others needs are plainly ignored with "we don't need this" argument. Meanwhile, even a power user is not a zealot, and many of those who could use and contribute to FreeBSD, do switch to other systems because of minor technical problems which were solved there (but not in FreeBSD) and the unwilingness of FreeBSD community to change anything. " And yet we complain on lack of manpower. > But if you want stable ports, you can deinstall all FreeBSD ports and > install those from pkgsrc. It works, is supported on FreeBSD and Yes, yes - deinstall ports, deinstall FreeBSD. That is not solving problems of ports. A bit of constructive. While writing this I've got an idea: why don't we introduce DEAD variable for this case? By default, it works as BROKEN, however it displays more verbose message like: ===> foo-1.0 is marked as dead. This means that the port's upstream has disappeared, it is not fetchable, is not kept up-to-date and may be broken or vulnerable. 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. This gives user a hint on what is the problem, how to build a port and what to do to fix a problem, and motivates him to become a maintainer. This satisfies me, as the user now has a chance to do what he needs, and I guess it should satisfy you as it does "poke the sleeping". Moreover, we can use it somewhat wider than BROKEN to mark some more dead (but still fetchable) ports (within reasonable, of course, as overuse will lead to TRYDEAD ending up in user's make.conf). -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru