Unhappy Xorg upgrade

[Alex Goncharov]

,--- 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 at gmail.com --