simpler package installation

[Justin Maurer <justin slashdot org>]

so, i've thrown the idea around on irc, and this is how i think things look 
so far:

1) allow users to install their rpm, without any suid binary involved.

	Q) How?
	A) Support a per-user db in addition to a system db, which rpm and 
	dpkg both support (i think). however, the problem with this is that 
	rpm (maybe dpkg, i don't know) requires chroot for the necessary 
	options to work. chroot, in turn, depends on being root, so this 
	portion of rpm would need to be redone.

	Since it is being passed in as an arugment, why not just take the 
	directory as a string, and prepend it to the files in the rpm, so that 
	/etc/conffile becomes $PREFIX/etc/conffile ? wouldn't this be possible?

	Q) Yes, but they must all be in the same dir, and this won't work for 
	programs with hard-coded paths!
	A) Sorry, that is not in the form of a question!

	Seriously, though, wouldn't it be simple to just have an option in 
	the spec file that says "OK, this package works with our new special 
	super option"? Then the gnome packages just have them, and others 
	don't.

	Q) But everything needs to go in the same dir, right?
	A) Pretty much, yes. So we just tell rpm that if it is an installing 
	an rpm in /home for joe random user, that user should only be allowed 
	one directory in which to install rpms. they might get to choose it 
	when installing their first program, but after that...

	Q) Couldn't users edit this dir and break shit?
	A) Yes.

	Q) My /home will be full with all my users installing applications!
	A) If you don't want apps installed multiple times, install them 
	system wide and be done with it. If you are worried about people 
	taking up too much space (without duplicates), then put quotas on 
	them. like i said earlier, people can find plenty of ways to take 
	up disk space without a (hacked) rpm.

	Q) Only that user will be able to use the app!
	A) Yes. If you want more than one user, you have two choices: install 
	it system wide, or tell the other person to set their environment 
	variables properly. i'd recommend the former.

2) Ok, this seems ok so far, but what about dependencies?

	Q) So, you want to remove a system package that a user's package 
	depends on. How does RPM know this?
	A) There are plenty of ways to handle this. George suggested keeping 
	the per-user rpm db in /var, which is certainly one solution

	Q) How about just plain old installing a package?
	A) Simple. Just check both databases to see if the dependencies are 
	met.

3) Ok, so what about a gui install program?

	I think it would be neat to have a user double click the program in 
	gmc and have it say "would you like to install this package for 
	yourself, or on a system-wide basis?" and then if the user says just 
	for himself, it goes ahead and does it. if they say system-wide, it 
	tells them they need to su to root and run rpm by hand, or ask their 
	sysadmin. simple, i think...

4) who is going to do all this work?

	i don't know. i *DON'T* want to be someone who says "OK, we have to 
	do this. you guys go get coding, i'll be waiting". so i'd offer to 
	help if people think it is a good idea.

5) Justin, you are a total idiot

	sorry to waste your time. i don't think this is too stupid, but maybe 
	there is something i am missing. please, remind me politely, without 
	flame.

-- 
Justin Maurer                                justin@linux.hypnotic.org
IFT Systems, Inc.                            http://linux.hypnotic.org
6717 N.31st Street                              Tel: +1 (703) 237-5511 
Arlington, Virginia, 22213 USA                         acf on LinuxNet