RPMs, tarballs and the poor newbie

I'm not asking for help here, before someone jumps in to tell me how to do "configure && make && make install" Oh and I don't want to hear how any BSD variants are better than this unless there's a suggestion of how GNU/Linux could learn from them practically Just wondering what people think about this issue...

RPMs.... they are horrid aren't they? They rely on a database of other rpms installed, so if you install something from source or as a tarballed binary, the rpm will still probably freak ouit because of dependency problems. And for some unknown reason, some rpms seem to randomly go in weird places unless you're careful. Grr.

Compiling from source is so much nicer, but then I'm odd like that, and I don't mind getting my hands dirty in a shell session.

What about the poor joe bloggs user who wants to install software? Are we ever going to get any solution to rival "install.exe" or a MacOSX disk image? I can't see how RPMs are going to get us anywhere, because they rely on their own database, unless someone can suggest a way in which you can *always* use RPMs?

the problem imho is:
macOS is ONE OS provided by ONE manufacturer (Apple) on ONE architecture (honestly 2, motorola 68k and PPC).

unix is 100 OSs provided by 100 manufacturers on 100 different platforms.

so RPM is imho a good way to make it work on all of them. sadly even RPM is not standardized enought to really do the job.

if you want to be a unix guru, always install from tarballs (best src-tars) and make up your OWN distro even if you are the only one that uses it...

Has anyone managed to maintain a system only using RPMs? I'm intruiged tbh because I don'tthink it's possible, and of course once you start compiling a few sources your RPM database becomes out of date. I'm wondering whether to reccomend pure RPM usage to "newbie" friends...

i did fairly well up to the point when i started to use programs that my distributor (SuSE) did not provide (yet).

RPM did a great job in setting up my basic system (1,5GB Server System). Now i need to write down which packages i updated manually and what changes were needed.

if you really want to stick to RPM 100%, make your own RPM packages. it´s not that hard!

but i recommend the "making your own distro" way

I think you touched on the one thing that really holds a lot of people back from Linux. I mean, to be honest which is nicer, Windows Installer or RPM? I've fudged up plenty a system because I got so fed up with RPM whining about dependancies that I uninstalled and ignored them. One time I had had Apache installed for about 5 mins, didn't do ANYTHING between the time I installed and decided to uninstall, and it STILL wouldn't let me because of some sort of critical dependancies.

I would prefer to build from src, but let's be honest, that just isn't an option for day to day users or really simple programs. We need to have something out there that users on all Linux systems can use to quickly and easily install programs on their systems. RPM is fine for apps that you know are going to be permanent on your box, but they just aren't the solution to quick and easy installs.

With debian packages, if I installed a package from source, and then used apt-get to install another package that relied on the first package, would it recognise it? Or does it rely on it's own database like RPM?

Personally, I prefer to compile from source. Though RPM's do have their advantages, and if done right can work well. Yes if you compile programs from source they won't be part of the rpm db, but you can install anyway by forcing. The trick is, if you are going to use RPMs be consistent. Check out an X application called Red Carpet, it will track and download, install all your rpm's easily. Yes it has limitations, but if you are consistent and only use source when have to, and document when you dont, rpms can work quite well. Though yes rpms are nowhere near ports in bsd, gettin there though. Or you could just compile from source =).
Nico

Of course the debian package management doesn't know anything about packages you install with ./configure && make && make install but it's easy to build your own debian-package from source by typing
apt-get -b source <package>
This downloads the source from the location specified in /etc/apt/sources.list and builds a .deb in your current directory.
Install it with
dpkg -i <package>.deb
and it is fully integrated in your system.
This is very useful when you want to install software which comes with a development release and is therefore not available in the stable tree.

BTW I agree with Nicomanchus that ximian's red-carpet is a handy tool. They really do a good job in making one package management system available on different distros (Although you wouldn't need it on debian because apt-get update && apt-get upgrade does it too if your sources.list is set up properly).

I had a thought, maybe someone can point out the absurdity of this suggestion?

It seems plain to me that of all the solutions for GNU/Linux, configure&make is the most reliable solution, but it is difficult to do, or put differently it lacks an easy way of doing it...

Could you not create a standard GUI program that is a wrapper for configure&make? My idea is that you could download a single file (say "setup.bin") which would contain all the dependencies the user may not have. When you run the file, it gives you a nice point-and-click gui that shows you the lisence, then the dependencies (and here it does a configure, and forks processes to install each dependency), then the files it'll install (make), then installs the files (make install). All the checking and compiling would be transparent to the user... they would just have to sit and wait for it to install. You could also have a net installer option where you download a smaller file without the dependencies included,and configure downloads any missing dependencies.

So it would be sort of like apt-get only it would actually compile the source for you, and it would be completely cross-distro compatable, not relying on any packaging tool...

Why reinvent the wheel?
IMHO the main part would be to maintain the package tree (your "setup.bin" files) and integrate new releases (I don't think that configure scripts describe their dependencies consistantly).
The people working on that for debian and freebsd for example do their job quite well from what I can tell and there are also people working on tools like GAR and GNUpdate.
Debian's dpkg and freebsd's ports system have also been ported to other distros (fink, gnu-darwin).
So before you want to go for ruling the world with another unified packaging system I'd suggest to help with porting/extending one of the existing ones.

I'm not intending to write another packaging solution. Not knowing any C, I'm not sure it'd be a very good one anyway! I'm just interested in the topic...

I don't see how making a GUI frontend to configure&make is reinventing the wheel... it's really just adding a nice axle and easier bolts to the wheel! The thing is that all package systems that rely on their own database come down to the same problem -- what if you have to do a manual compile? The package system will suddenly not recognise the newly installed files, and so will slowly become redundant.

In fact I found a binary that sort of did what I thought up - it was a binary to install and set-up the drivers for a Lucient Winmodem, and it went through a few stages (shell admittedly, not GUI) giving you the opportunity to pass extra options, then went through configure && make && make install. Of course I'm fairly sure various configure scripts aren't consistent in their reporting missing dependencies. Could the system be set-up so that the person writing the app configures the installer so it will understand the configure output? So the end result would be consistent...

Please don't get me wrong - I absolutely agree that a common packaging system for different flavours of unix/linux would be great (if it's really a common frontend to ./configure... the question would be why you would still need anything else).
Probably I failed to describe where I see the biggest problem:

> Could the system be set-up so that the person writing the app
> configures the installer so it will understand the configure
> output?

You can't expect anybody to do anything how you want it to be done. Actually I wouldn't accept that either. That's what open source is all about - do it your way.
autoconf/automake are widely accepted tools. I don't see much chance if the system won't be able to deal with almost all configure scripts out there.
Of course I know that starting off an existing software collection doesn't solve the problem you mentioned in the first place at all.

You wouldn't Do away with RPM... horrible system. apt-get could still be useful though for binaries (quicker than any compile).



Not entirely... there are all kinds of standards that people have to obey, otherwise we'd never get anywhere. It's a matter of finding good standards and integreating them into the system/community, just as has happened with configure&&make... not that I think I'd ever get a standard introduced Just contributing to the general discussion around this....

From where I see it, GNU/Linux won't ever go desktop mainstream until an improved, or a new install standard is worked out...

I may appear like some sort of a linux extremist, guess I am. But I don't think we can yet say that Linux will never go mainstream or on the desktop. Look how far/fasy it has come in only a few years. I know Linux has a lot of critics, many of them are even UNIX geeks/professionals. Saying, "Linux doesn't have this or doesn't have that or can't do something." Well honestly, I think those people are missing the point or grand design here. The object of Linux is to eventually have all those things, it is premised as a gradual work in progress. The gap of things that it doesn't have, no one can really argue, gets shorter every week.
Eh, I just wanted to rant about that a little=) Not directed at anyone, I agree we need to get better install and package management systems-of course. I think we will though, that's what we're working towards. Well just my thoughts ..
Nico

Couldn't agree more :-) I don't care for the pointless news articles always being posted saying "Linux will make it on the desktop in X months" or "Linux won't ever make it on the desktop". Give it time...