Slashdot Mirror

You must install into some temporary directory

I'm sure he knows this since he is already using Stow. Stow works pretty well for having multiple versions of different software packages built from source and installed simultaneously, and having a proper package management system for it all. Though these days I use Checkinstall - having the final package as a .deb or .rpm make it a bit easier to distribute the built packages.

Once it's in the main repository you can upgrade using synaptic, else download the tar.gz file and extract to a /tmp location and type the following five lines, at a command prompt:

Or you could just use CheckInstall, thus obviating the need to bypass the package manager.

Or, compile yourself and install via checkinstall. I'd think if you were halfways aware of how to administrate a Linux system, you already know how to compile a tarball. Checkinstall builds the package, .deb or .rpm, and installs it for you. Then, you can add the package to your local repository.

> When it comes to Debs, I have no idea how to build Debs.

FYI:
I think the ``Correct Way'' is:

1. Either download directly or use apt-src
2. then: dpkg-source -x $package_name.dsc
cd $package_name
dpkg-buildpackage -rfakeroot

Or you could *try* to use apt-build (but I don't know if they ever got that to work as advertised).

In a hurry you could also use "checkinstall" http://asic-linux.com.mx/~izto/checkinstall/ (which is a sort of hack for packages without the files to use the first two suggestions).

Cheers,

do you mean something like checkinstall

http://asic-linux.com.mx/~izto/checkinstall/

now that is easy easier than building an install for windows.

compiling your own packages also got a little bit harder with removal of checkinstall for slack 12.
it didn't work quite well with recent coreutils.

hopefully, checkinstall will get updated and included back, but in case somebody just wants it to get working fast, replacing 'chmod' from slack 11 made it so much happier.

changelog recommended monitoring http://asic-linux.com.mx/~izto/checkinstall/, so that's probably something i'll do for some time :)

I would suggest you to use checkinstall.
It's a wrapper for "make install" that creates a package and installs it, so that the software:
1) Gets cataloged on your system's package manager, and
2) Can be easily removed with the normal system package tools.

I made a nice script that guess all the fields of package information, like name and version (from the dir name, or from date, in case of cvs/svn/git), and pass them to checkinstall for a non-interactive one-shot install. If anyone is interested, just ask and I'll post it here.
I works very well on Slackware, and now I'm adapting it to Debian too. (I also switched from Slackware to Ubuntu, but because of hardware support. It's not that easy to configure the kernel and required software these bluetooth/dvd-burner/usb/cellphone/digicam days.)

You can use checkinstall to keep track of exactly what it changes though.

Your ideas are intriguing to me and I wish to subscribe to your newsletter. Actually, I'll just provide this link I found to the CheckInstall site, in case anyone else is interested.

Also, run the installer as a regular installer and you can be sure it's not touching anything outside of your $HOME.

A lot of installers will just abort if they aren't allowed to run rampant.

Even better, extract the files by hand and run them. :)

Yeah, that's my usual solution.

In this case, I trusted the setup script inside the .bin, and I gotta say it worked pretty nicely. Lets you run it as a regular user, and it installs everything into one directory (plus an optional symlink somewhere else). I think I even saw mention of an uninstaller. Yeah, Google will take over the world. :)

SMART Package (meta)-manager is kind of nice.

Add in YaST repositories, APT, YUM, RedCarpet, or just dumps of RPMs, DEBs, whatever. Add in all the mirrors you can think of (it automatically prioritizes them by download speed). I find it convenient to also have a local "RPM" directory, where I drop random packages that I want to install. This is my local "repository".

It's slick, it handles conditional dependancies nicely, and it doesn't choke on "broken" systems the way apt does (sometimes you WANT to leave your system partially broken, the SuSE pygtk2 nonsense comes to mind). It's not _yet_ production quality, but its pretty damn good. I expect a lot out of version 1.0.

Oh, and if you want to install from source .... get checkinstall, and possible Kommander (latter is buggy). Checkinstall does ./configure, make, and make install for you, but does it in a chroot, and then builds an RPM. You can then manage this RPM like any other.

Pretty slick, huh? Kommander is a GUI front end, which relies upon checkinstall.

http://kde-apps.org/content/show.php?content=13134
http://asic-linux.com.mx/~izto/checkinstall/

The other nice thing about smart: with basic options, its just like synaptic or kynaptic, but "slicker".

I digg it :)

But they're all (for the most part) compatible, and programs like Alien and Checkinstall make it easier. The same functionality is basically in all of them. And most of them are free.

To use, go the usual
./configure
make
then (as root) checkinstall

Try it out!
http://asic-linux.com.mx/~izto/checkinstall/

I'm using 1.5.3 and 1.6.0 doesn't seem to like me, but its as simple as ./configure, make, checkinstall -S (instead of make install) and it'll make install a slackware package that you can remove with pkgtool like everything else.

I think Checkinstall 1.6.0 just plain doesn't work. First, you have to make sure you use the new "--install=yes" option, but even then only about 1% of programs work with it. The only one I got working was TightVNC, so I switched back to 1.5.3 again.

I hope nobody looks into Checkinstall, downloads 1.6.0, and thinks it's utter crap immediately after trying it...

On that note, here are links for all the relevant packages:

Source
SlackPack TGZ
RedHat RPM
Debian DEB

I'm using 1.5.3 and 1.6.0 doesn't seem to like me, but its as simple as ./configure, make, checkinstall -S (instead of make install) and it'll make install a slackware package that you can remove with pkgtool like everything else.

I think Checkinstall 1.6.0 just plain doesn't work. First, you have to make sure you use the new "--install=yes" option, but even then only about 1% of programs work with it. The only one I got working was TightVNC, so I switched back to 1.5.3 again.

I hope nobody looks into Checkinstall, downloads 1.6.0, and thinks it's utter crap immediately after trying it...

On that note, here are links for all the relevant packages:

Source
SlackPack TGZ
RedHat RPM
Debian DEB

I'm using 1.5.3 and 1.6.0 doesn't seem to like me, but its as simple as ./configure, make, checkinstall -S (instead of make install) and it'll make install a slackware package that you can remove with pkgtool like everything else.

I think Checkinstall 1.6.0 just plain doesn't work. First, you have to make sure you use the new "--install=yes" option, but even then only about 1% of programs work with it. The only one I got working was TightVNC, so I switched back to 1.5.3 again.

I hope nobody looks into Checkinstall, downloads 1.6.0, and thinks it's utter crap immediately after trying it...

On that note, here are links for all the relevant packages:

Source
SlackPack TGZ
RedHat RPM
Debian DEB

I'm using 1.5.3 and 1.6.0 doesn't seem to like me, but its as simple as ./configure, make, checkinstall -S (instead of make install) and it'll make install a slackware package that you can remove with pkgtool like everything else.

I think Checkinstall 1.6.0 just plain doesn't work. First, you have to make sure you use the new "--install=yes" option, but even then only about 1% of programs work with it. The only one I got working was TightVNC, so I switched back to 1.5.3 again.

I hope nobody looks into Checkinstall, downloads 1.6.0, and thinks it's utter crap immediately after trying it...

On that note, here are links for all the relevant packages:

Source
SlackPack TGZ
RedHat RPM
Debian DEB

(yes I still don't know how to uninstall a generic packages..like when I download something, untar; make; make install : where can I find out where it put all it's stuff?).

I had the same problem for a long time until I found out about checkinstall. Basically, you install it and do your whole build process as normal except you type checkinstall insetad of make install. It makes a package for your distro from the newly compiled software and then installs it. That way, you can later uninstall such software using your distro's built-in tools.

I believe it currently supports the package systems for Debian, Red Hat, and Slackware.

(yes I still don't know how to uninstall a generic packages..like when I download something, untar; make; make install : where can I find out where it put all it's stuff?)

Easiest way is probably to use Checkinstall. I'm using 1.5.3 and 1.6.0 doesn't seem to like me, but its as simple as ./configure, make, checkinstall -S (instead of make install) and it'll make install a slackware package that you can remove with pkgtool like everything else.

And now, how do I uninstall it,since the Makefiles don't seem to have make remove/uninstall/etc. that would delete the installed binaries.

Checkinstall is what you're looking for. Even for unsupported package management systems you can at least have an inventory of files installed (or changed).

What I'd like is a slackware package builder that does it all for me so I can then install the package and distribute it for others. Oh, and a money tree wouldn't go a miss, along with a frictionless enviro-friendly engine ... thanks!!

Try checkinstall. You run it as the final step instead of "make install", and it will automagically generate and install a package for you. It runs perfectly for me under slackware 10/10.1. I think a tgz is available in the slackware extras/ directory, even.

However, I have heard complaints from people who don't like how it arranges the directory structure (putting stuff into /usr/local, etc). They may be correct, but the packages *do* work just fine on other systems.

I argee. Plus apt-get isn't distro specific. apt works for debs and rpms. It probably works with most all linux installations, as at works with some of the biggestest players: Debian(namely Ubuntu) and Redhat (Fedora through freshrpms and apt-rpm).

Apt is solid stable, easy to use by commandline. Synaptic is better than most GUI package tools. I don't see how a "minimalistic" and young distro specific pacage manager could even compete. Though the name is cute it doesn't install confidence in me.

No, i haven't tried arch, but i'll probably give it a try. But to say that pacman is even on the same level of power and ease as apt is really hard to swallow. Any pacman advocates out there? Care to explain why Arch uses yet-another-packaging-system?

For my money apt and checkinstall is the simplest to use, most powerful and robust packaging system around. I'd challange any comers.

For those that have never heard of checkinstall, it's a wonderfull little utility that captures the "make install" stage of compiling programs yourself. It looks at what "make install" stage does and rolls a .deb or .rpm automatically. Last I checked it didn't work too well with fedora, but it works great with Ubuntu and apt. No more guessing what you have installed on your system, or headaches removing or upgrading custom built software. Easy to use too. Install of make;make install it's make;checkinstall. Bingo, custom built package.

Apt and checkinstall. A system maintainers dream.

Sorry for the tangent.

I'm on my second installation of LFS. It's not for those in a hurry, that's for sure- It takes me about a month to get a VERY basic system. (Think X and Firefox, and not much else!). I inevitably make some bone-headed mistake, and I don't back up while installing, so it's my fault.

Also, building something like gnome from source really teaches you the meaning of 'dependency hell.' Seems like every single package requires exactly version "1.1211-1243pm" of every OTHER package, and even some obscure RedHat patches too, in some cases. *Shudder*gDesklets*Shudder*.

However, I have a VERY good idea of what's on my system and what libraries are being used where. There's NO 'fat' or extra stuff that I didn't put there. I used to shy away from compiling from source- which makes sense on a package-based system. Now there's NO fear. There's even a few interesting package management schemes for compiling from source.

Booting into my brand new, hand-built, bare-bones system- it's almost as good as if I'd written the software myself :) (And as close as I'll ever get)

That's all nice... *if* you're using Slackware packages all the way. The fundamental problem doesn't really lie in Slackware's package management. It even has an 'apt' now, named 'slackpkg'. The problem for me lies in the poor availability of packages for Slackware compared to other distributions like RedHat and Debian.

Have you not heard of CheckInstall?! Anything I put on my Slackware box is in package form. If I have to compile something (this includes Perl modules) I build from source and then use CheckInstall to install. For Perl modules it's just a little wrapper script I have that won't eat perllocal.pod. It's trivial to make Slackware packages and it's trivial to keep any Slackware system that the admin has been wise enough to use packages up to date. Seriously. Check it out. I dislike the RPM/DEB package system because of the dependencies. it's too much work to make decent packages. Slackware eliminates this and really, what's so difficult about seeing "libfoo.so not found" and installing the foo package? Not for newbies, granted, but for any admin it's not a big deal. At all.

That the real problem, it's not getting stuff to work, is getting rid of it when it's not needed anymore.

If you dont mind compiling from sources, but uninstalling is your headache you could take a look at checkinstall

./configure
make
sudo make install

./configure
make
sudo checkinstall

I think you are refering to checkinstall (http://asic-linux.com.mx/~izto/checkinstall/)
To p stuff, build things from source, then remove or reinstall or whatever with the slack pack system.

Take a look at checkinstall This cool package replaces the "make install" step of app installation, and can create a Slackware, RPM or Debian package and install it for you.

So linux isn't ready because if you choose to use software distributed as source you have to use the commandline? It's not even a terribly hard sequence of commands, and they are almost always described in the INSTALL document.

That aside though, the main issue with source installs is that you end up with a mess - files all over the place. You can't remove what you just installed unless the Makefile happened to include an "uninstall".

Up until now I've been very happily avoiding this issue by using stow, but recently I found checkinstall which you run instead of make install. Checkinstall creates a package (.deb, or .rpm based on your system) containing all the files getting installed by the make install step, and installs that for you. That means that everything, source installs included, can be conveniently managed from whatever package management application you use (I prefer synaptic myself, it works for anything that supports apt, which includes rpm).

"That's still too hard!" you say? Yes, quite possibly - but then the only real reason to be installing from source is if you have very particular needs (special configure options) or a need to be on the bleeding edge. Pretty much anyone who thinks compiling is too hard should be happy with binary installs. With things like synaptic, redcarpet, up2date, etc. around installing distro provided packages is a breeze. If you have to go outside your distro try autopackage. Yes, autopackage isn't finished yet, but they're at the stage where they have some test packages (install the latest version of inkscape via autopackage for instance), and what they do have is fantastic - think of it as installshield with advanced dependency checking resolution. All those third parties currently supplying distro specific rpms ought to shift their project to supplying autopackages, and certainly autopackage looks to be the way to go for any commercial vendor who wants to create a linux installer for their software.

Installs are still a little tricky, but the issues have been spotted, and are being worked on - and the solutions look better than anything Windows provides.

Jedidiah

Like Gentoo, LFS doesn't do much to teach you what's going on -- it's a set of instructions to follow, while Gentoo is a ... well, set of instructions to follow. How many people actually step beyond these directions when something breaks? Not a good lot of them if the Gentoo/LFS forums and IRC channels are any indication. "Wuhh x broke, what do I do now?" is all too common, much like Ask Slashdot postings where the answer is found by plugging the question into Google.

I've always seen an inherent problem with source-based distros that don't actually make you get down in the muck and bugger with the source -- They give you a little more insight but really it's just a package-based distro which happens to use the source tarballs and prefab patches and Makefiles to make the build tool happy and consistent. You're really no further ahead with Gentoo or LFS than you are with Mandrake or Debian or SuSE.

If you want to learn the internals stop using a hand-holding distro, grab Slack, cut your teeth building stuff that wasn't on the CD (or try remaking something from the CD!)... Then realize that it's a royal waste of time and a security risk requiring a compiler on every system and making your first few packages... Learn the intracasies of trying to make Perl module packages or Apache shared libs that can be used on several systems. Now grab something like CheckInstall to make your life just a tad easier and learn all its weirdnesses. Break things and try to fix them, and then realize that you now have some really solid foundations to truly learn how Linux works.

Now that the foundations are laid, go build some small i386-based systems using nothing more than a dev environment and chroot. Don't cheat by grabbing a buildroot. LFS helps give some direction here, as do the busybox and uclibc mailing lists. When you can build these and understand what's going on, you've actually learned how Linux works and how the pieces fit together. Go tweak a kernel or write a driver for some nifty piece of hardware to round out your knowlege. You've now got enough of an education to get a decently-paying job in the embedded systems industry. Round it out with some good networking experience from packet dumps and screwing around with raw sockets and such and you have got a really solid technical background for practically anything Linux.

Now I didn't say the process was for everyone, and I certainly didn't say that this is how everyone should learn it. I'm just getting sick to the teeth of people claiming they know how Linux works and how to build programs when all they've learned how to do was run "emerge someprogram" and give dumb looks if it doesn't go right.

If you are look for the benefits of a package and you use Slackware, try checkinstall.
Just configure the sources, make them and before installing use this programa, it will make a good slackware packages, and you will get the benefit of remove or update packages in a clean way!

If you have the time to compile from source, and have slackware, debian, or use RPMs, you can use checkinstall (found here: http://asic-linux.com.mx/~izto/checkinstall/ ) to make packages from source. Works great under slackware in tandem with pkgtool, as it gives you the optimizations that you need along with the benefits of packages.

that is why you use a program like checkinstall to do the job AFTER you compiled and tested everything.

I build gobs of packages this way for my LUG members. it works great and makes sure that your changes made are replicated throughout all machines.

Most of the time I find that the deps a pre-made package wants are simply resolved by compiling on my machine with my versions of the libraries.. cince I am in control of my suite of machines, I prefer to roll all the packages used for all the machines I control so I know all of them are identical.

Basically, nothing get's installed until it goes through my testing server first. eliminates all problems you mention and gives me the power to have apps that are not available as a precompiled package.

nobody can find me a current webGUI mandrake package with all the security patches added... or a myphpnuke in the same state... but I can make that package that I know will install across all 15 servers.

I'm running Slackware 9.1 on my laptop, when ever I need to install a package I first look for a slack pack. If none are available I then download the source, ./configure && make && checkinstall. Checkinstall then spits out a nice slack pack for me to install or uninstall without any hassle. The benifit of this is that I can configure the build how ever I want but still have a nice package to install and uninstall when ever I need. Checkinstall can also make .debs and .rpm.

Build your software from source and then create a package. Distribute and install the packages. It is a trivial matter if you use Slackware. Other distributuions are not too difficult if you use the checkinstall utility. You get the best of both worlds.

What about if one uses ./configure && make && sudo /usr/sbin/checkinstall --install=yes ?

I'd really like if the autoconf tools (configure and friends) would get a small extension that just displays (or better yet, saves to a central location) the locations of all files that were just installed. Just so that I don't have to dive into a Makefile (or 90 pages of ./configure --help) to figure it out.

1. CheckInstall will generate DPKG files (among many package formats) for anything you build from source. Makes it easy to uninstall the files.

2. What APT repository were you using? Did you search for the package at apt-get.org to see if there were any third party repository? You know that you can have several repositories in your sources.list file, right?

How should a package manager handle the user overwriting files left and right with different versions? The policy is that you put YOUR stuff in /usr/local and leave the rest alone. If you don't want to do that, creating your own Debian packages _really_ isn't that hard.

Just use checkinstall, it will make you a deb.

(Here)

I wish you'd tried out checkinstall. It builds packages (deb, rpm, even slack) from ordinary old tarballs. Anybody using Linux with a package-based system should have it installed.

• your program has a particular appeal to newbies and it is not included with most distributions,
• the build procedure is unusually complex, or
• your program takes ridiculously long to build.

If you decide to do it anyway, one tool that can help you is checkinstall. It monitors the standard make install process and can create several kinds of packages. I doubt the quality of the generated packages is very good though, and you still have to take in account that different distributions have different policies.

Also, make sure you don't waste effort creating packages for distributions that already include your program. You mention DEBs, but whatever your program is, I'm pretty sure Debian already includes it :)

some background: linux user for the past 7 years.

My preferred package is Slackware Packages. debs, RPMs (RedHat and SuSEs), Gentoo ports... all ugh. Slackware packages do everything you want for installs, and almost all of the uninstall stuff. Where almost every package managers fall apart is in uninstalls. Slackware does so too, but without crapping up the install in the process.

CheckInstall does wonders for Slackware, Debian and RPM-based systems. I am planning on contributing code which allows you to apply a patch -- not just blindly overwriting a file. Perfect example: Perl modules. Module installs add to perllocal.pod. CheckInstall will write the new perllocal.pod into th epackage. Not so good.

Another place where package managers fall down is dependencies. I'm sorry, but no package manager on the planet does package management right. Slackware doesn't pretend to do it at all, which is great. And I mean what's the worst that happens if you're missing a dep; a pretty straightforward error in most cases. Admittedly "can't resolve pz_requiredFunctionHere()" isn't clear, but some work can be done to clearly separate the dependency database from the package manager, and bolt on something to do the deps. Deps should _not_ be integral to the package.

Finally, a personal gripe about Debian; while their source packages are by far the best in the biz, rewriting the man pages to change practically every reference of Linux to GNU/Linux and blindly overwriting the author's configuration locations to fit into "the Debian way" goes too far sometimes. Uniformity in the distro is good, but there's been more than one occassion where the Debian man page was just plain wrong compared to the author's original.

Even better. Use checkinstall to make an RPM. It takes any hassle out of making a .spec file, and you wind up with an RPM (or a .deb or a Slackware package).

There are already several programs out there for creating debs and rpms from tarballs. With Debain, installing a package with a valid version number allows for a subsequent version of the program from the apt repositoires to replace your compilation. The point is that it is getting easier to place your own compilations into the packaging path. Checkinstall is one such program.

I'm one of those people who insists on compiling everything myself and not using packages. I do this because I like to have some control over what options are used when compiling and that everything is optimized to run on my machine.

Gentoo is the Mandrake of Slashdot... You don't learn how to do anything besides run emerge. May as well run apt or urmpi, IMO.

LFS is pretty cool but time-consuming. Slackware seems to strike a very happy medium. Using CheckInstall to make Slackware packages for anything I compile by hand, I get every benefit of Debian or pretty much all the RPM based distros without all the overhead and central control.

A happy Slackware user since '95.

If it exists for Linux, it's probable that it's packaged in RPM format.

Of course, for both deb and rpm, there's the excellent checkinstall

Apt-get makes dependencies a thing of the past.

That's something I've never fully understood. Why are dependencies so farking hard to observe? I mean to a fresh newbie or someone who just doesn't have the time or interest in it, sure, but I've found apt to be more of a pain in the ass than anything else.

Disclaimer: I've been using Slackware since shortly after it first came out. I believe my first install of Linux was with the 0.99.x kernels, but it may have been the early 1.x.x kernels, I really can't remember.

Slackware's biggest bonus (and fault) has been that it lets you do as you please with packages. It'll let you install a package without having its dependencies installed. You run the app, and you get an error. Usually something along the lines of a library missing.

Now this isn't what I'd want a newbie to see or do, but for someone who's familliar with the system you run ldd on the binary and find out what's missing and install it. No big deal.

Especially now that CheckInstall is around, I have absolutely no issue with Slackware -- -current has logrotate which was sorely missing from the distro, but Checkinstall's the best. Create Slackware, Debian or RPM packages with a touch of the keyboard. Parallel installs, links, everything's supported.

Back to Slackware's packaging. What I disliked about Debian or RPM was that if the package didn't exist you had to go hunt around trying to find it and hope someone else made it, or else make it yourself, perhaps using Checkinstall. Unfortunately both RPM and DEB have heavier requirements -- dependency trees, documentation in the right spot, patches to make it fit within their particular file structure... you either use Checkinstall to make the package poorly (but validly), or you set out on a mission and end up being the maintainer of every package you make. Slackware doesn't care, which is great for me.

Sure Debian's got 10k packages, but it seems that everything I need isn't there, isn't complete, or is old, even in the unstable tree. FreeS/WAN with NAT-traversal and SA-disconnect, GNU-Radiusd, Psi, mplayer... that's just off the top of my head. If I don't install via packages (this goes for Perl modules from CPAN, too!) I now have TWO package managers to take care of -- the one in my head and the one in the distro. For me, Slackware compliments the one in my head (or vice-versa).

Anyway enough ranting -- I just don't understand how for anyone who's been using linux for any amount of time cares about dependencies. Even with upgrades.

RPMs never seemd to work across distros, quel suprise. This is one thing that I really like about slackware's .tgz files.

And some things aren't RPM-packaged.

One tool that *no* RPM user should be without, IMHO, is checkinstall. This runs a normal "make install" after you're done with ./configure and make, but monitors what locations files are being "install"ed to. It then builds an RPM package and installs it. This lets you cleanly uninstall tarballs, and handles library dependencies. In many ways, it gives you the flexibility of Slackware's approach with the nice features of RPM.

Look at checkinstall

If this was integrated with urpmi (or something else that did automatic dependencies) then any gui installer could really kick some butt, because whatever it installed would be available to the package manager, but the installer could install however it wanted.

For Red Hat-based systems, at least, rpm -V will do pretty much exactly what you're looking for.

From the man page for rpm:

The general form of an rpm verify command is

rpm {-V|--verify} [select-options] [--nodeps] [--nofiles] [--nomd5] [--noscripts]

Verifying a package compares information about the installed files in the package with
information about the files taken from the package metadata stored in the rpm database. Among other things, verifying compares the size, MD5 sum, permissions, type, owner and group of each file. Any discrepencies are displayed. ... The (mnemonically emBoldened) character denotes failure of the corresponding --verify test:

S file Size differs

M Mode differs (includes permissions and file type)

5 MD5 sum differs

D Device major/minor number mis-match

L readLink(2) path mis-match

U User ownership differs

G Group ownership differs

T mTime differs


So while that's a bit cryptic, a shell script run once every x days (30? 14?) should tell you what files have changed. All you would have to do is run rpm -qa to grab a list of the packages in your system, and then loop through the list and run rpm -V for each RPM returned.

For instance, running rpm -V on two common packages, Apache and PHP, shows me the following:
# rpm -V php
S.5....T c /etc/php.ini
(php.ini has changed... which in this case means I've tweaked some of PHP's default settings.)

# rpm -V apache
S.5....T c /etc/httpd/conf/httpd.conf
missing /var/www/html/index.html
missing /var/www/html/poweredby.png
(Okay, I've changed httpd.conf, again pretty much a given, and I've removed a couple of the default files.)

I guess this website seems pretty unneeded to me. Granted, the above is just for RPM-based systems, but I'm sure Debian and ports have similar options. And to the people who have installed from source and say "What about me?", I say, first, never underestimate the power of a package management system, and second, check out CheckInstall, which allows you to create an RPM or DEB just by saying "checkinstall" instead of "make install". If you feel you must compile from source, checkinstall is a necessity! Using checkinstall gives you all the benefits of a package management system while still allowing for the flexibility that compiling from source provides.

Between checkinstall and up2date, I'm a very happy Red Hat customer. I just wish more people knew about some of the truly powerful things in package management systems (such as the verify command detailed above.) Package management systems are there for a reason. Use them! :)