[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde
Subject:    RE: The Ultimate Installation/Unistallation Method
From:       "Timothy R. Butler" <kde () uninetsolutions ! com>
Date:       2000-09-21 3:38:49
[Download RAW message or body]


> packages (things like the "OpenSSL or not" issue discussed earlier),
> so people do commonly encounter problems with dependency issues when
> trying to use RPM's for Mandrake vs. Red Hat, etc.  This just
> generally makes a bigger mess for the PM's intended audience (via the
> various distros); newbies.

  As I said, if the package can survive with OpenSSL, don't set it up as a
dependancy. If it can't run without it, no package manager can fix that, IIRC.

>
> The normal user wants to be able to download a package and install it
> without worrying about whether they have glibc-2.2.1-10 vs.
> glibc-2.2.2-mdk5 and having packages complaining about this.  They

  Agreed, but how will YaPM fix that? If you need 2.2.2-mdk, you'll still need
2.2.2-mdk with YaPM. If you don't, the dependancy level should be lowered.

> don't want to worry about "oh, well you need fnlib, imlib, libjpeg,
> libpng ... to install this"; they just want to download the package
> once and have it install with no problems, regardless of whether
> they're using Red Hat, Debian, or something else.  The user DOESN'T

  That would be nice, but that is something the programmer has to take time to
work on. YaPM would have to be extemely smart to know all the little differences
between distros (and correct them). Otherwise, whether using RPM or YaPM you'd
need to start doing some scripting - it's necessary evil.

> CARE about the differences between GNOME and KDE; he/she expects that
> if they download a piece of software and try to install it, it will
> work.

  Exactly.

> I think what we need is a package manager that handles all this.  The
> PM should take care of the KDE/GNOME menus, it should take care of
> the glibc-2.2.1 vs. glibc-2.2.2 issue (although it would be nice if
> the distributors would handle this...), and it should take care of
> all the other dependency issues AUTOMATICALLY.  Ditto for uninstalls.

  RPM, like I said can easily add menus - just one command in the install script.
Glibc 2.2.1/2.2.2, problems can't be solved, IIRC, without a new version of glibc
(if it truely needs the newer version). The best way to fix this, would be to have
KPackage offer to go fetch the needed packages for you - something that would
require an update to KPackage, not RPM.


> When the user wishes to install an application, they will download a
> .xin file which contains an application component, and zero or more
> components upon which the application depends.  The user tells the
> system to install the .xin file, and the system handles the
> installation/upgrade of dependencies automatically based on the
> dependent components that were provided in the .xin.

  The problem with including all dependant components with it, is that not
everyone is using broadband. I don't want to download 100 megs of stuff just to
install Kicq, for instance. But, to fullfill all dependancies, Kicq would need to
include all of KDE, the right glibc, the right libicq, etc. Loads of unneeded
stuff.
  Even Windows requires you to find a few libraries on the net sometimes. It's
different on CD-ROM, but when downloading, it just isn't practical.

> Similarly, when an application is uninstalled, the system removes the
> application component and checks to see if any of the dependent
> components are still in use by other applications.  Those that aren't
> needed anymore will be automatically uninstalled.

  As long as our user here didn't compile his own app that needs that library...
then he uninstalls foobar, and all of a sudden wizbang app 2.0 (user compiled, not
packaged) can't find hello-world-lib.

> We will also want to allow recursive dependencies (an application
> depends on a component which depends on another component), but I
> don't think we need to make allowances for this in .xin's.

  YaST does something like this when first installing a system.

> Options (such as custom configuration on install) can be added to the
> system as well (but those creating components should remember that
> the components may be installed by newbies), to fix some of the
> issues that RPM does not address.  Another feature might be the menu
> system; GUI apps can specify that they are to have menu
> entr(ies)...the PM would take care of adding the KDE or
> GNOME-specific files required.

  By using shell scripts (in RPM), rather than built in functionality for this (in
xin), the user wouldn't have to update the package manager if, say, GNOME moves
the location of it's menus.

  Any way, it seems to me, by automating this stuff, you also cause problems that
don't happen now - like the package manager being out dated every time a DE
releses a new version. Also, a few lines of shell script don't sound unreasonably
hard, especially hard enough to create YaPM.

   Just my $0.02...

   -Tim

-----------------------------------------------------------------
Timothy R. Butler                              Universal Networks
Information Tech. Consultant    Christian Web Services Since 1996
ICQ #12495932 AIM: Uninettm       An Authorized IPSwitch Reseller
tbutler@uninetsolutions.com        http://www.uninetsolutions.com
===================== "Solutions that Work" =====================



-- 
Send posts to:  kde@lists.netcentral.net
 Send all commands to:  kde-request@lists.netcentral.net
  Put your command in the SUBJECT of the message:
   "subscribe", "unsubscribe", "set digest on", or "set digest off"
PLEASE READ THE ARCHIVED MESSAGES AT http://lists.kde.org/ BEFORE POSTING
**********************************************************************
This list is from your pals at NetCentral <http://www.netcentral.com/>

[prev in list] [next in list] [prev in thread] [next in thread]