xorg 6.9 removal

xorg 6.9 is going to be removed from pkgsrc soon; upgrade to the modular version when the chance presents itself. As the linked post says, you need these packages:

  • meta-pkgs/modular-xorg-apps
  • meta-pkgs/modular-xorg-fonts
  • meta-pkgs/modular-xorg-drivers
  • x11/modular-xorg-server
  • x11/xterm

(Though xterm can be replaced with other terminal programs) All these are available as packages from your local mirror, though programs dependent on X will need to be recompiled or reinstalled from binary packages.

8 Replies to “xorg 6.9 removal”

  1. Call me crazy, but when i go looking for something like X.org in the meta packages directory, I’m kind of expecting to find one package that would install all the X.org components… and if I was looking for individual components, I’d look under the x11 directory…

    What were the pkgsrc folks thinking when they set it up this way? Is it a short term thing until the monolithic X.org is gone?

  2. Well, what was I thinking?

    – modular-xorg-server is redundant, it is a dependency of the driver package
    – xterm is not really part of modular Xorg
    – you often don’t need or want all the drivers or all the fonts

    So I considered the need for a modular-xorg meta package to be relatively low.

  3. Well, thanks for the response, and fair enough for your part in things. Obviously to get the answer I wanted, I *should* have asked my silly question to the pkgsrc folks, but I posted it here because the only reason I care at all about pkgsrc is becase its what DragonFly uses ;^)

    Personally I’ve found it handy to have multiple drivers on hand… twice now I’ve had video cards die out on some older boxes I have, and I’d imagine its somewhat of a time saver not having to download the rest of the drivers, power down, swap card, reboot, maybe tweak xorg.conf etc. but that’s just my take on it.

    Even on the oldest machine I have running, disk space isn’t whats lacking…

  4. Starting from the -drivers meta-pkg is certainly non-obvious, says I who went through this a few times. When it comes to discovering the appropriate technique, it’s a little awkward to have things split between the two directories, even if there’s a strict logic to it; keeping to that logic, the solution would have to be a meta-pkgs/modular-xorg package for those who want to cross their fingers with one target and hope something working comes out.

    I hope the Radeon driver(s) in 7.x can actually derive modes from DDC/EDID data now, or widescreen users are going to be in a world of hurt when 6.9 is dropped. (In other words, I was banging my head against that a few months ago and haven’t checked recently, I *think* a lot of progress was made since then.)

  5. The ATI driver has improved a lot over the last month. Why do you think it would be a regression? You can still use normal modelines in modular Xorg.

  6. Exactly, it was a major regression a few months ago (March?). Finding a working 1440×990 mode (or just getting the server to run without locking up) was rather difficult at that time.

    If it’s fixed it’s fixed, if it’s not I guess I’ll find out when I test the current state of things this week, heh.

  7. I think there should definitely be only one package that installs the batch. The -server package is installed as a dependency, but that doesn’t really make the process any clearer. You still have to go figure out that the -drivers, -apps, and -fonts package are what you need. Having xterm as part of the bundle doesn’t hurt anything, either.

    The need isn’t as dramatic now as it was when there were no meta packages at all for modular xorg, but there’s certainly good reason to make the process easier, given how often xorg is installed.

  8. Technically the choice of terminal would/could/should be just another make option, but that’s gold plating and a balcony for the bikeshed.

    [Frankly, that would be a good place to keep the list of available terminal choices, since x11/ is full of stuff, but someone would have to maintain it…]

Comments are closed.