On Fri, Sep 08, 2000 at 11:15:20AM +0200, Ingo Luetkebohle wrote:
> On Thu, Sep 07, 2000 at 03:14:32PM -0400, Mark Shewmaker wrote:
> > Great! I had previously thought that if the gnome libraries weren't
> > installed or were corrupted, that GnoRPM couldn't be used to fix the
> > problem. I had not known that the program was written to somehow
> > fallback gracefully if gnome libraries are missing; I had assumed
> > you would have to use rpm directly.
>
> Uh. No, thats not what I meant. The *librares* are needed. Thats not
> so much different from other graphical libraries, though -- without
> libX11, it gets hard. However, you don't need to run other *programs*,
> which could be a problem on low-memory machines. As it stands, gnorpm
> requires 4MB of memory on my machine, which is not exactly small but
> comparable to glint IIRC.
And that was my point.
The context was a claim that although a graphical software installation
program is nice, it would technically be more useful if it didn't
require gnome. The response was that it doesn't require all of gnome.
My reply was to point out that it is dependent on the gnome libraries.
A desirable technical feature in a software-installation program
running in an environment X (haha, made a funny) is that it require
no more resources than it takes to simply run X. Otherwise you run
into situations in which the installation program won't run until you
install something with an installation program.
The rpm program itself is statically linked (presumably) to solve
that problem. As objectionable as statically linking code is in
many cases, I would think it not so very objectionable in the case
of even something like GnoRPM. (!) I can imagine that there will be
a lot of folks who find it useful who are confused by commandline rpm.
(I'm not counting those who merely complain at the lack of rpm
documentation. :-) )
Hmm. I just thought of something that could be an alternate
solution: If GnoRPM used dlopen's to link to its libraries,
and the dlopens failed, it could conceivable simply pop up
a text window telling the user of the need to install specific
libraries via specific names of rpms, .debs, or tar files.
Simply including detailed newbie-friendly instruction or automatically
running a shell script to do the installation if the user is agreeable,
would answer my objections. I've got to think about that..
(I do tech support for another unix. The re-installation of the
installation program when shared libraries are corrupt is an
issue that comes up from time to time, but we've got a documented
procedure on how to do it to point customers to that requires only
installation media and nothing else. It would be nice GnoRPM
were self-documented such that it could explain or initiate such
a procedure when the need arose.)
> I think that statically linking everything, like /bin/rpm does it, is
> only feasible for command-line tools.
Although I would agree with that in most cases, there are other
justifications for statically linked code, on of which IMHO is
to make sure installation programs at the very least more gracefully
fail in the absence or corruption of shared libraries than the
programs they would be used to install do.
When code fails and someone goes to their normal installation program
to diagnose the problem, that program should be hardened enough to
be able to at least give helpful advice when it doesn't have enough
information to run properly.
(Note: I don't consider this a major failing of GnoRPM, and in fact
I hadn't thought of the solution of printing out detailed instructions
or running a script until writing this email. The issue of what
an installation program should do if there's not enough of the system
working right for it to run properly is something that's almost
completely uncoupled from the design of the rest of the program,
of course.)
-Mark Shewmaker
[EMAIL PROTECTED]
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
