Slashdot Mirror

You must be either joking or trolling with your comment about RH.

Not at all. RedHat adds or modifies particular functions within the standard Linux kernel. It was several years ago when I researched this but there's no joking or trolling involved. My memory is hazy (and they may have stopped this practise now) but I believe they either modified the call to fsync() or added a variant of it. As I said, it was several years ago that I did this research.

How can tweaking a kernel lock you into a distro?

Because you can't upgrade the kernel from the standard kernel tree without patching the added/modified functionality in. IIRC there isn't another distro which does this.

Why don't you install apps from source if you don't like rpms? But I'm curious, how do you uninstall if the 'make install' drops files all over the filesystems? Lots of software doesn't include a 'make uninstall' afaik.

I do install from source. However if you use regular tarballs (i.e. there isn't an RPM or SRPM, you now have two package managers to worry about: RPM and the one in your head. Any distro based on packages has this fault. If you're using a package-based distro, chances are that you don't want to worry about this. You want the ease of installation and maintenance. Anything they don't provide, you become the maintainer for.

As far as 'make install' dropping files all over the network: It's called Checkinstall, and it is a godsend. It basically preloads a library to wrap normal fs functions which audit the install process so nothing is missed. Works for Slackware, RPM and DEB.

Ever heard of apt? Yes, it works with rpms (and damn fine too, I might add).

Yeah, I've started playing with Debian. It's a damned fine distro, although their exuberance about PAM and tattooing "GNU/" in front of Linux whenever possible doesn't jive with my personal preferences. Packages are great for checking out software, so long as there is a package available for it. (Binary) packages eliminate the need for a compiler suite on a system, which is a good thing. See my comment above about installing from source and its issues on package-laden distros. It takes some getting used to, but trusting dpkg works for the most part. Where it fails is when the package maintainer decides to bundle certain apps that really are not needed for their package (kde is a prime example of this).

The --rebuild and all of the -t* options are now run with rpmbuild. You need the rpm-build and rpm-devel packages for this. I do believe this was discussed in the release notes (I read them during the install of (null)).

Seems like a good idea to me, I hope a new version of checkinstall is released soon that supports RH 8.0.

If you follow the stoopid /. suggestion, and compile/install the new OpenSSL you are going to leave RPM nirvana and enter "random untracked apps linked against random untracked libraries" hell.

Checkinstall should be a good way to get around this. After compiling you use checkinstall instead of make install, and it'll create an rpm and install that.

You might want to try CheckInstall. Never used it myself, but it promises to the job on RPM, Debian and Slackware. I think the next time I do a distro upgrade I'll try it, I've done the source tarball thing so much on my box RPM has no idea what's going on.

> This is true, but I would rather have small, fast,
> solid base system that can be easily added to.
> Something like Gentoo with an installer.

I agree that I don't use of the apps on my RedHat distro. But unlike Gentoo et al. all I don't need to download each new app I may need. apt-get/emerge might be a neat idea, if you have either a flat or broadband. For me per-minute modem user they're unavailable :(

Still, RPM's ability to watch the dependencies is a good idea. They can save you a lot of hassle when you're about to deinstall a package on which other packages rely. This is the main advantage over vanilla windows.

Unfortunately, this only works for the RPMS and not user compiled apps/libs. But I read about checkinstall, which creates RPMS out of ./configure;make;make install software.

> I think the initial install is something Linux
> has improved on, I actually like Mandrake's
> DrakeX more than Windows' installer.

Getting Linux on your harddisk is pretty easy nowadays. And I think vanilla Linux is already far better configured than out-of-the-box Windows (i.e. I don't need to install drivers for half of my hardware).

It's getting Linux to do all the small things you like it to do. That's the pain in the ass. For example, you want to view encrypted DVDs under Linux. Ok, you got Xine already installed, but nada, that'S not enough. For menu support you need Xine-DVDnav. Oh wait, DVDnav requires libdvd and libdvdcss. Each library needs to be d/l'ed seperately, you need to compile/install the libraries, you need to take care that the version of Xine-DVDnav and Xine are compatible... sheesh, I only want to watch the occasional DVD. Got my point? ;)

> I liked 2K more than XP, and don't get crashes
> because I am picky about the code I run on my
> system. I have had 2 crashes on my XP system;

I had a few more, but I could always trace back the source of the error. Most times it was my fault (wrong driver etc); only Mozilla made my XP box crash totally on certain webpages, and even then not the whole OS crashed, only the GUI did (which may have the same effect, but Winamp, for example, still played my MP3 collection).

Secondly, no elegant way to integrate software that hasn't committed to one of the packaging systems into an architecture. Both RedHat and Debian both work great when you stick to rpms and debs, but just try installing the latest version of a piece of software that doesn't have an rpm or deb yet, and you run into a world of pain.

$ ./configure
$ make
# checkinstall (*)

• builds your choice of a .deb or .rpm or Slackware package,
• installs it,
• saves it in (e.g.) /usr/src/packages/RPMS/<arch>,
• saves a .tgz of the sources in (e.g.) /usr/src/packages/SOURCES/.

(*) or else 'checkinstall your-install-script'

It's called checkinstall and is available here

Now that looks like a useful tool, whether one will build RPM packages, or something else. It looks like the installwatch part could be useful during Linux From Scratch installs. Hope it works the right way inside chroot, which should be fine by making it part of the base system.

Checkinstall

What I would hate to see are any major revisions if it's just gonna add some feature; I would rather see that time spent on developing the ports and packages themselves. Make is a good, simple, foundational and almost always present solution. Adding other languages would be a waste of time IMHO.

Let me condense what I think should be pursued from the ports perspective: documentation and ease of use. One can always make readmes and get mini-descirptions, but that really should be expanded upon, both for beginners and seasoned users who just don't know what that software is about. It would be nice to have some options like, info that would go thought the ports tree and build more verbose information. If those documents are built in a consistant manner (such as xml), then any ol' front end can be built to pull the info on the port and automate building the port and the flavors available. For example, a simple curses interface that will inform you of the dependancies that will need to be built first, estimates the size, and gives you a list of flavors to add into your build. Hit ok and it monitors the progress for you, logs the process and keeps the messages out of sight (from those who get scared easy).

I agree that something should be done to be able to automagically build a package from a port. I think this area would be the best to pursue. Even better, if we bsd types could get a system like checkinstall /installwatch consistantly, not most of the time, but consistantly working on BSD. This project essentially is a wrapper script that records everything make install does. In current form, it gives you the option of building an RPM from that make install. What should be pursued is making this work -well- on bsd, with the option to build a package along with documenting it's dependancies and/or recording the install info into the existing system to that all one has to do to remove what you just built is 'pkg_delete'. THAT would be cool!!

...the package management system, which rocks, but only as long as you are just installing pre-made binaries. I never tried to create a RPM, but making a .deb from some arbitrary code you downloaded is definetly way to much work...

You should investigate checkinstall. It makes making a .deb (or a .rpm or .tgz (for slackware) for that matter) as easy as a single command. Sure it doesn't take any dependencies into account, but you can't have everything :)

If you want to compile a package from source, use apt-get -b source package . If you want to install a new non-Debianized program from source, use a tool like checkinstall.

Use checkinstall. Run it instead of make install and it'll create a rpm | tgz | deb package to install (and uninstall, if need be) with your packaging system.

On my RH systems, I often download tarballs and build from source in /usr/local, but I install using checkinstall which creates an RPM on the fly by monitoring the package installation. Then I can have the benefits of package management (especially uninstall and query capabilities) while keeping up-to-date on sources.

I did, & it was the least buggy Linux "distro" I have ever had. Use it with checkinstall/installwatch In case you screw something up.

Just want to recommend that all RH users (and slackware too) check out checkinstall.

It's a utility that automagically changes tarball installs into RPM or slackware package installs.

I run it like this:

./configure
make
make test (if necessary)
checkinstall

Checkinstall first installs the build into a temp directory, builds the RPM or slackware package, and then installs the package.

I've been using it for the past 8 months and it's saved me many times from giving up on the RPM database. The developer is working on getting Debian pkgs going too.

It's available here.