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

List:       kde
Subject:    RE: The Ultimate Installation/Unistallation Method
From:       "Joshua J. Berry" <condor_des () yahoo ! com>
Date:       2000-09-21 3:07:48
[Download RAW message or body]

My $.02...how about this:

We could build YaPM (I know, I know, there is RPM and DEB, etc.)
(what were we going to call it? xin?  What does that stand for
again?) that easily and simply addresses these concerns.  As a
developer, I don't want to have to spend time writing shell scripts
here and there inside RPM to deal with "well, am I installing on KDE,
or maybe GNOME, or...".  I think that is the responsibility of the
package manager.  RPM does not currently provide adaptability to its
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.

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
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
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.

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.

The packaging system should probably be broken into two pieces; one
that handles the various "components" and their installation/removal
(libraries, etc.; what RPM and Debian call "packages"), and another
that handles the relationships with components (a "package" or
"application" as defined in .xin terms should be a collection of
components that holds both the application itself and some or all of
its dependencies).

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.

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.

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.

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.

We may also want to include compaitiblity with RPM's and DEB's, which
can be installed as application/library components via the .xin's
standard installer routine.

In any case, here are my two cents' worth.  As I said before, I would
be willing to work on the back end of this packaging system.  I have
some C++ experience already, although I couldn't write KDE-specific
code as I haven't even finished the Qt tutorials.

-- Josh

--- "Timothy R. Butler" <kde@uninetsolutions.com> wrote:
> Hi Casey,
> > Let me also say, that xin's should have an automatic unattended
> installation
> > option, which would be used for (in the future) xin-based
> distributions, or
> > by newbies - in fact, when a user downloaded and opened a xin in
> kde (using
> > kxin), it should say Automatic or Custom? or something of that
> nature.
> >
> > With the command-line tool, it should be a command line option. 
> I.E.
> >
> > xin --automatic package.xin
> 
>   Right.
> 
> > Also, every option within the xin should be available as an xin
> command line
> > option, the way a configure does.  For example,
> >
> > xin --with-ssl=/usr/local/ssl --with-qt=/usr/lib/qt2.2.0-final
> --enable-ssl
> > --installto=/opt/kde --automatic kdelibs-2.0.0-linux.386.xin
> 
>   Unfortunately, the qt part, AFAIK, would not work. If the file
> was compiled with
> QT 2.2.1 or 2.1.0, it might not work with 2.2.0 without a recompile
> (perhaps 30,
> 60, or 90 minute endevour). The install to part can be accomplished
> using
> the --prefix option on RPM packages that were made to support it
> (up to each
> developer). As I said, most of this stuff can be done with RPM -
> btw, what can't,
> most likely can't because people don't take advantage of all RPM
> can do.
> 
> > The --automatic would make all options not specified
> automatically choose the
> > default.
> 
>   This could be done with a bit of fancy RPM work. Here's what you
> could do: have
> the RPM install to /tmp/foobar , and then have the GUI or command
> line script ask
> "auto" or "custom" (automagically after RPM has been started).
> 
> > So that an automated script (as used when installing a
> distribution), could
> > make use of this, and still use standard xin files
> (non-distro-specific).  A
> > distro could also be made a lot more intelligent with this.  For
> example, if
> > a user choses not to install openssl, AND ssl support is
> *optional* in the
> > program, for example licq, then the package could still be
> installable - to
> > the user it would look the same, but the installer would run this
> in the
> > background:
> >
> > xin --with-qt=/usr/lib/qt2.2.0-final --disable-ssl
> --installto=/opt/kde
> > --automatic kdelibs-2.0.0-linux.386.xin
> 
>   Once again, I think this would require a recompile. If it
> wouldn't, it wouldn't
> using RPM either, once again AFAIK. Just remove the SSL dependence,
> and make the
> install script access the RPM package tree or ask the user about
> it.
> 
> 
> > Options presented would be determined by an internal config file
> within the
> > xin, which should actually be a tar.gz of all program files for
> compatibility
> > purposes.  The magic would be in the config file.
> 
>   IIRC, this is how the Debian Package Manager works. Not a bad
> idea, but then
> again, if you need that kind of compatiblity, Deb already is
> working and has lots
> of packages.
> 
> > Proposed file-naming standards:
> >
> > (package)-(version.version.version)-(platform).(processor).xin
> >
> > Examples:
> > example-0.3.2-linux.686.xin
> > example-0.3.4-bsd.386.xin
> > example-0.2.0-solaris.sparc.xin
> > example-0.3.2-linux.sparc.xin
> 
>   This is similar to the RPM naming convention, right?
> 
> > Distribution would not be important.  That would be detected in
> the install
> > process and specific functions for each distribution if necessary
> would
> > reside within the config file.
> 
>   Actually, it isn't right now (for the most part). I can install a
> RedHat package
> on SuSE, a SuSE package on Caldera, and a Caldera Package on
> Mandrake. Each might
> locate stuff in different places, but this has nothing to do with
> RPM, and
> everything to do with the Distribution Companies. This too could be
> taken care of
> in an install script.
> 
> > As shown, the . should change to a - for the directory, no other
> changes.
> > This way, the xininstaller will know what directory to change
> into.  The
> > config file should be stored in the first directory of the
> archive, like
> > this: ./example-0.3.2-linux-386-xin/config
> > The config file should operate like this:
> > The installer will scan the system and provide variables to the
> config file.
> > the config file will be coded something like this:
> >
> > if unix=solaris then do
> > 	(
> > 	something or other;
> > 	another;
> > 	)
> > endif;
> >
> > if unix=linux-redhat then do
> > 	(
> > 	lock installto=/usr;
> > 	set brokenprogramnamehere=true;
> > 	)             <-- here goes distribution quirk-fixes :)
> > endif;
> 
> 
>   This would be very nice, however, if it supports Solaris and
> RedHat at the same
> time, the file size would be 2x the normal size since it must be
> recompiled (or
> contain two binaries) for this to work. Once again, this is to do
> with the
> manufacturer and not RPM.
> 
>   If the purpose of your suggestion is to create platform
> independence, that is
> pretty tricky. That was way Java was created - but while it works
> on multiple
> plateforms fine, it doesn't do a great job on any. It's also slow.
> The only way to
> achieve this kind of compatibility (IMO) would be to wait until we
> get 25 GHz
> processors, and then have the software compile as it's installed.
> 
>   Perhaps I'm missing something, but I really think RPM or DEB can
> do _everything_
> you are talking about with a little work with setup scripts.
> Anything lacking
> could be added, certainly both package managers are robust and
> stable - a new
> package manager would take years to gain the support and stability
> of RPM and
> DEB...
> 
>    -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/>


=====

---------------------------------
"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

"It's very inconvenient to be mortal -- you never know when everything may suddenly stop happening."
    -- /usr/games/fortune

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/
-- 
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]