Help with rebuilding xorg-server
 

Hi I want to apply a simple patch to the xserver, hopefully to correct stability problems I'm having with Slackware 14.1 http://cgit.freedesktop.org/xorg/xse...6219d88aa1091d

I was looking through the Slackware source tree and I don't see a slackbuild just for xorg-server, I just see an x11.slackbuild which is huge and contains tons of stuff.

How do I rebuild just the xorg-server? I'm out of my depth on this. Thanks.

Slackware still uses the monolithic SlackBuild but you can easily use the BLFS method on Slackware here to build the modular specific package:

http://www.linuxfromscratch.org/blfs...nstalling.html

Follow the introduction to X11 and check Slackware's ldconfig files and use the directions to install to /usr. Then rebuild x-server as described here:

http://www.linuxfromscratch.org/blfs...rg-server.html

LFS build methods are very similar to Slackware, so it should work without any issues.

No don't do that. Just run after patching the source (or simply put your patch in directory slackware-14.1/source/x/x11/patch/xorg-server before running the command).

You'll get only xorg-server packages, not the whole X stack, and build doesn't take long.

Have a look at x11.SlackBuild, you'll see it's modular, it builds either all sources or all sources in a directory of./src or a specific source in a directory of ./src

Thanks bro. Should make this a little easier.

I know you switched from Slackware to LFS but please avoid giving biased answers like this one. Tell people how to do it the Slackware way. That is better in the long run.

Eric

Yikes. I was using wget -r to download the x11 directory from a slackware mirror and I didn't know it recursively downloads everything both ways. I only downloaded about 160MB before realizing this, but live and learn, I learned the --no-parent option. Anyway marking this as solved and thank you.

For that, lftp comes handy:Even easier, just mount the DVD or the ISO image that you could have at hand ;)

There should not be any real difference as long as it's the Linux way Eric. Saying there is a Slackware way, is saying that the SlackBuilds have some magic difference between the traditional ./configure, make, and make install method other than installed path and build options. From past reading into how Slackware does things, Slackware attempts to hold true to the traditional Linux or UNIX way of doing things.

I'm not going to argue that point, but it just seems a bit outside the norm to say that the traditional methods are not going to work on Slackware that emphasizes the traditional as norm.

I did misread the x11.SlackBuild file as completely monolithic, but it is structured to be just that, with standalone arguments for individual packages within.

You completely miss the point here. Slackware packaging system brings both ease of maintenance and ease of customization. Maybe you don't value that, but most Slackware users do.

Yes, but aside from packaging how is doing it the traditional UNIX/Linux way going to differ than using a SlackBuild with equal or near-equal results?

The point I made and clearly was missed was that make install and make uninstall should have nearly the same effect on a source package as installpkg and removepkg against a pre-built from source package minus documentation which often is installed with copy-pasting sometimes.

Package management is fickle as an argument to make anything easier or more difficult. That's almost like saying the Ubuntu way, the Red Hat way, or the Arch way is superior to the traditional Linux/UNIX way.

If I'm not mistaken, or taking this out of context, even Alien BOB himself said once somewhere that using a SlackBuild should produce the same results as traditional ./configure && make && make install against a package minus the additions of options, paths, and extra dependencies used.

This sentence clearly shows that you don't know how Slackware packaging system works. It maintains a database of files installed and removed in:
/var/log/{packages,scripts,removed_packages,removed_scripts}
so that you can any time put back your system in a previous state, with no need to keep a note of everything you did, no need to keep source bundles, nor packages themselves but to ease re-installing them. This works both ways:

• You know instantly what each and any individual installed file came from.
• You know instantly which files were installed or removed by an installpkg or removepkg command.

Plus, you should know that using relying on make install & make uninstall only:

• Makes you depend on skills & methods of upstream packager (if any), that widely vary. Just think that sometimes there is no uninstall target, or another tool than make is supposed to be used.
• Won't give you a database of what has been installed/removed.
• Make you need to keep each and every source bundle to be able to use make uninstall.

Still, you are free not to use the Slackware packaging system, but then IMO there is no point in running Slackware (that is consistent with your decision to switch to LFS :-)

A database can easily be maintained with a simple text file if you're willing to do so. I keep my entire collection of source packs in my /sources directory, and manually log and track where packages are installed. It's extra work on my part, but I know my system inside and out.

Just because different tools offer to ease the workload doesn't mean you shouldn't learn for yourself how packages install and file tracking.

As anyone knows there are times you don't have the luxury of a SlackBuild script and have a raw package. You should know how things install without a script set and without a package manager. Just because a script set doesn't exist is no excuse for not being willing and/or able to know basic administration skills and techniques.

What I meant with "the Slackware way" was not to dismiss the use of "./configure && make && make install". The strong point of Slackware is that it is absolutely painless to use this - there is no package database like RPM which enforces you to use the package manager exclusively "or else". I do this a lot, for quick tests of software.

Having said that, messing with X.Org is not the same as compiling a simple program from source and installing it (possibly even in /usr/local). The X.Org subsystem is complex with lots if inter-dependencies. Knowing how Slackware builds and installs X.Org, and using that knowledge (i.e. use x11.SlackBuild) wisely is the best way to minimize breakage. Also using the Slackware x11.SlackBuild to rebuild individual components allows you to revert easily to the original situation, should breakage occur.

Note: "make uninstall" requires that you keep the program's sources and compiled binaries on your computer indefinitely, while "removepkg" does not require you to retain anything at all.

Eric

Then you can write a SlackBuild yourself.

Yes, once you know what paths you need, and can draft up not only the script, and maybe installer specific scripts also, provided, but that's still not an excuse for not knowing.

Politics about it aside, if you have a GNU/Linux system, you should know the administrative basics, period. Relying on someone to do everything for you, and relying too much on automation only promotes ineptness and lacking of critical knowledge.