Unhappy Xorg upgrade

vehemens vehemens at verizon.net
Sun Feb 1 10:31:02 PST 2009

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.  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.

> | 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.

> | > 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.

> You may assume that X is going to be fixed -- but what if not, in, say
> a year?

Your kidding me right??

> | 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 ?!?!?

> | 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.

> | > | 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.

More information about the freebsd-ports mailing list