Re: Some things GNOME really needs

[Miroslav Silovic <silovic zesoi fer hr>]

Victor Bogado da Silva Lins <bogadofuture@openlink.com.br> writes:

> >         1) you'd have to run a /huge/ executable as root. Security
> > issue waiting to happen.
> 
> 	I don't think so, every installation even today needs root privileges.
> When you do make install you're actualing running a application that
> copy every file needed. In fact the library that all the gnome intall
> programs would use could have some security checks (like asking before
> writing anything into a already existing/nonrelated file) to make
> installation procedures even more secure.

This is irrelevant, the fact that you're running an executable still
stands. How do you know it's calling the library at all? How is the
library supposed to check that the program doesn't have interesting
sideeffects (like overwriting /bin/login, or even better, seeking
other executable installs and infecting them with code that seeks
other executable installs... etc)?

> >         2) you lose autoupgrading, dependency checking and
> > installation monitoring that RPM/.deb gives you.
> > 
> 
> 	In original post I sujested that the library would update this dbs,
> this could easily be done by making it modular, so if you use red hat
> you would have a rpm-db module installed that would place the apropiate
> entries in the rpm database, the same if you have debian or any other
> package management that will be invented.

Point taken, that's 1 out of 4.

> >         3) you end up with a subtly different installation procedure
> > for each application.
> 
> 	I am clueless, my idea is to end with this problem!

See windows installation wizards.

> >         4) you have deinstalls that should work (in theory) but never
> > quite do - bugs in the install wizards may have SEVERE side effects
> > and since every intall wizard is rewritten from the scratch (modulo
> > library), bugs remain plentyful.
> 
> 	This I agree in part. In many cases the basic library would do all the
> job to uninstall, but you could never be 100% shure in every
> application.

In fact, the DOS/Windows experience told me that about 1 in 10 apps
deinstalls itself correctly. And the apps writers must have had a
reasonably good starting point.

> > I think dos/windows approach teaches us what should *not* be done.
> > 
> 
> 	I agree that the windows/dos way in many ways the wrong way, but we
> could not say that a idea is bad just because dos/windows use it. In my
> opinion linux/unix have a big problem in this area that also appears in
> windows.

What I'm saying is that the way it failed in DOS/Windows show us that
the approach is wrong from the start. Requiring every app writer to
also write some extra code that mangles your system's guts and
expecting it to actually work is silly.

> The fact that every program share a single dir (in unix /usr/bin,
> /usr/lib, /usr/share, in windows c:/windows/ and c:/windows/system)
> this turn unistallation a nightmare.

That's precisely why packet management was written in the first place.

> RPM (deb I don't realy know, but I guess it does the same) solves
> the problem in a good maner creating a hierarchy of packages, but
> this is complicated for the brainless user.

I don't know debs either, but the earlier discussion on this list
seems to indicate that debs are closer to the mark. And some more
earlier discussion shows that hierarchies of packages are not that
much of a problem.

Note that hierarchy of packages is less complicated than cleaning up
after a failed uninstall. Brainless users tend to run to overworked
technical support to reinstall Windows for them whenever that happens.
And it happens a lot.

Trully brainless users should not install software - they don't even
under Windows (for suitably narrow definition of brainless).

> 	I think my idea is good and would realy makes thing easier to
> the end user.

I beg to disagree.

> RPMs and Deb files are quite good, but they are not the best of the
> worlds.

Quite true, but making each app manage its own (de)install is
demonstrably worse.

GNU HURD claims to have solved the problem on the filesystem level -
it can make things in different directories appear to be in the
same. I'm not sure how it handles dependancies and I don't have any
practical experience with it, perhaps there are HURD hackers (pun
unintended) on this list who could elaborate.

> Many times when you try to install something a RPM complains the you
> do not have XXX or YYY, shure there is the webfind that searchs for
> dependences automagicaly, but my experience is that don't work 100%
> of the time.

If it complaines that you don't have everything you need to run your
program, why would you expect it to work? Packet manager could/should
be able to locate dependancies for you. It's not a sufficient argument
to move packet management to executable level.

> 	And off course there are always the programs that are not yet
> rpmfied or debfied, then you have two options config/make/install
> them and never getting rid of them or simply wait till a rpm/deb
> file is available.

How is that different from a program that doesn't have self-extracting
installation program you're talking about available for it?


In conclusion, why would anybody /bother/ inventing a new installation
mechanism when the problems with the current could be solved more
easily (and more safely) by enhancements to the present systems (like
embedded RPMs and pre/post scripts mentioned in another post)?


-- 
I refuse to use .sig