From owner-freebsd-ports@FreeBSD.ORG Sun Feb 1 19:22:54 2009 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A270106564A for ; Sun, 1 Feb 2009 19:22:54 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id A7C7D8FC26 for ; Sun, 1 Feb 2009 19:22:53 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA09.westchester.pa.mail.comcast.net with comcast id AddF1b00D0ldTLk59jNuHf; Sun, 01 Feb 2009 19:22:54 +0000 Received: from daland.home ([24.34.211.11]) by OMTA04.westchester.pa.mail.comcast.net with comcast id AjNt1b00Z0FJTGg3QjNuPp; Sun, 01 Feb 2009 19:22:54 +0000 Received: from algo by daland.home with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LThu8-0005oy-EN; Sun, 01 Feb 2009 14:22:52 -0500 From: Alex Goncharov To: vehemens In-reply-to: <200902011034.50759.vehemens@verizon.net> (message from vehemens on Sun, 01 Feb 2009 10:34:50 -0800) References: <200901311153.58361.vehemens@verizon.net> <200901311354.43031.vehemens@verizon.net> <200902011034.50759.vehemens@verizon.net> Message-Id: Sender: Alex Goncharov Date: Sun, 01 Feb 2009 14:22:52 -0500 Cc: freebsd-ports@freebsd.org, alex-goncharov@comcast.net Subject: Re: Unhappy Xorg upgrade X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 19:22:54 -0000 ,--- You/vehemens (Sun, 01 Feb 2009 10:34:50 -0800) ----* | On Saturday 31 January 2009 04:20:26 pm Alex Goncharov wrote: | > ,--- You/vehemens (Sat, 31 Jan 2009 13:54:42 -0800) ----* | > | > | On Saturday 31 January 2009 01:25:21 pm Alex Goncharov wrote: | > | > So, a *fundamental* (practically an OS component) port is brought in | > | > -- and it disables my system. What is my way of action? Right -- | > | > install the old packages, taken from an FTP site (is there a way to | > | > get the previous "source", that is all the ports/*/*/Makefile files? | > | > Csup can only go forward -- or can it go back?) | > | | > | You ignored the first part of the email which is that the ports | > | system is flawed due to the lack of a stable versus current branch. | > | > The FreeBSD model as what it is and I, for one, prefer it to Linux | > distros' models. In other words what you call a flaw, I call a | > virtue. | | Your missing the point. Oh well, my fault then. | This has nothing to do with Linux. The issue is that that while src | has a stable versus current branch, there is no stable branch for | ports. The result is major updates are almost always problematic. Any data points to support the last statement? | > | It seems to me that you want to run a stable branch, while the ports | > | tree is effectively a current branch. | > | > If somebody tells me that running the new X on my computers will be | > better if I switch the base system from STABLE to CURRENT, I'll do it | > in a heartbeat. (In fact one of my other systems does run CURRENT, | > only I never installed X there -- I don't use that system as a front | > end.) | | The issue is with the ports approach, not the base system (aka src) approach. | See above comments. I am missing the point here, again. | > | > When I install the old packages, I can no longer rebuild and install | > | > new (say `csup'ed on 2009-03-01) port components, as one whole -- I | > | > can only do it selectively, excluding from the upgrade most | > | > X-dependent things. That sucks and will lead to a problem earlier or | > | > later. | > | | > | I never update /usr/ports directly. I have a separate csup ports | > | area. When I update, I save the old ports tree and replace it with | > | a new one. If a problem occurs, I can fall back to the old tree or | > | pieces of it. | > | > An interesting model -- but how would you be better off falling back | > to the old ports tree in case of a bad (for you) new X? Yes, you | > could rebuild and return to using the old X. Then what? Would you be | > able to keep up with ports upgrades. | | You wouldn't be able to keep other updates unless you manully patched the | tree, but you would be able to use the system until it's fixed. What the ETA for the new X fix? | > You may assume that X is going to be fixed -- but what if not, in, say | > a year? | | Your kidding me right?? No. You *know* that it is going to be fixed in a year? If yes, what's the source of your knowledge? What resources are going to be dedicated to work on my three problems? | > | Well, it depends on which ports you are updating. | > | > All. | | Your saying that you build every port including the language options and never | had a problem in the last 18 months until the xorg update ?!?!? Yes, I am saying exactly this. I happen not to run Gnome or KDE. | > | If you only run X, then I would expect your statement to be correct. | > | > Not sure what you mean here: nobody "runs only X". It's impossible. | | To be precise, it's the xorg port. So yes it's possible. Hm, let's see: ---------------------------------------- Information for xorg-server-1.5.3_2,1: Depends on: ([ I exclude the "X things" ]): Dependency: expat-2.0.1 Dependency: openssl-0.9.8j Dependency: pciids-20081012 Dependency: e2fsprogs-libuuid-1.41.3_1 Dependency: python25-2.5.2_3 Dependency: pkg-config-0.23_1 Dependency: libpthread-stubs-0.1 Dependency: libiconv-1.11_1 Dependency: gettext-0.17_1 ---------------------------------------- Plenty of non-xorg things are needed for xorg, right? And if I build from the sources, I also need gmake, bison, autoconf etc. | > | > | And last, many of the video drivers have little if any support. If | > | > | you have something other then ati/intel/nivdia, you should expect | > | > | problems. Input drivers are in a similar state. | > | > | > | > Both my systems I've been reporting problems with are using the `nv' | > | > driver: | > | > | > | > $ grep /modules/drivers /var/log/Xorg.0.log | > | > (II) Loading /usr/local/lib/xorg/modules/drivers//nv_drv.so | > | > | > | > One system (Dell Latitude) could not be made operational with the new | > | > X at all; the other has garbage in the windows and the "captive mouse | > | > pointer" -- both issues new in the new X. | > | | > | See above :) | > | > Which point? :-) | | All of them. Ah, I got you now. -- Alex -- goncharov.alex@gmail.com --