Message-ID: <Pine.LNX.4.64.0911050019540.1469@artax.karlin.mff.cuni.cz>
Date:	Thu, 5 Nov 2009 00:55:53 +0100 (CET)
From:	Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>
To:	Martin Nybo Andersen <tweek@...ek.dk>
cc:	kevin granade <kevin.granade@...il.com>, Valdis.Kletnieks@...edu,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Ryan C. Gordon" <icculus@...ulus.org>,
	Måns Rullgård <mans@...sr.com>,
	linux-kernel@...r.kernel.org
Subject: Re: package managers [was: FatELF patches...]

> > On Windows, the user can just download the EXE, run it, click
> > next-next-next-finish and have it installed. There is no package
> > management that would try to overwrite what you have just installed.
> 
> Exactly. There is nothing to help you from installing incompatible software 
> (ie libraries). If your next-next-next-finish installer overwrites a crucial 
> library, you're screwed. The package manager, on the other hand, knows about 
> all your installed files and their dependencies and conflicts.

The package manager can make the system unbootable too --- because of bugs 
in it or in packages.

In some situations, the package manager is even more dangerous than manual 
install. For example, if you are manually installing new alpha-quality 
version of mplayer, and it is buggy, you end up with a working system with 
broken mplayer. If you install alpha-quality version from some package 
repository, it may need experimental version of libfoo, that needs 
experimental version of libfee, that needs experimental version of glibc, 
that contains a bug --- and you won't boot (are rescue CDs smart enough to 
revert that upgrade?)

> If you really want to fiddle with your own software versions, 
> dependencies, and conflicts, then the equivs package is a perfect 
> helper, which lets you create virtual Debian packages (empty packages 
> with dependencies and such). For instance, I compile mplayer directly 
> from the subversion repository - however I still have some packages 
> installed, which depends on mplayer. Here the virtual mplayer package 
> keeps apt and friends from complaining.

Nice description ... the problem is that for desktop users it is still too 
complicated task.

I think the ultimate installer should work somehow like:
- extract the configure file from the *.tar.gz package.
- parse the options from configure (or configure.in/.ac) and present them 
to the user as checkboxes / input fields.
- let him click through the options with next-next-next-finish buttons :)
- try to run configure with user's options.
- if it fails, try to parse its output and install missing dependencies. 
This can't work in 100% cases, but it can work in >90% cases --- if we 
fail to parse the output, present it to the user and let him act on it.
- compile the program on background. (or foreground for geeks :)
- run "make install" it into a temporary directory.
- record what it tried to install (for possible undo) and then copy the 
files to the real places.

At least this would allow Linux users to use a lot available free software 
without relying on what the distribution does or doesn't pack. The user 
would work just like in Windows, download the program from developer's 
webpage and install it. He could upgrade or downgrade to any available 
versions released by the developer.

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists