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

List:       kde
Subject:    Re: The Ultimate Installation/Unistallation Method
From:       Casey Allen Shobe <cshobe () mediaone ! net>
Date:       2000-09-21 0:47:21
[Download RAW message or body]

Andreas Pour wrote (on Wed, 20 Sep 2000):
> Perhaps my problem is I don't understand your proposal.  IIRC you
> mention building something on top of existing packaging systems, but
> don't provide greater detail.

Look up the original post - perhaps I shoud repost, anyways, it's not 
building on top of anything, it's an entirely new format, the installer of 
which would support existing systems, such as RPM, so that your dependency 
tree doesn't get broken.

> There are a lot of specific fields in the rpm database -- e.g., what a
<snip>

See my post on how the config file would work.

> Well, certainly glibc and libc5 aren't.  I also don't think glibc-2.0 is
> compatible with 2.2.  But in any event you run into further
> complications with compilers:  given the current name-mangling issues
> with C++ compilers, you cannot mix-and-match C++ libs.  That means every
> single C++ app/library has to be compiled with the exact same C++
> compiler.  Since different distros, and even different versions of
> distros, use different C++ compilers, there is no one-binary-fits-all
> solution.  In the end you will need to have a binary for each
> combination of libc/glibc and compilers.  Now you are pretty much back
> to the rpm-based system.

Only in one respect.  There are still countless advantages over RPM - 
besides, I'm pretty sure it would work.  For example, the staroffice binary 
installs on pretty much any linux system, regardless or libc version - but I 
could be mistaken, in that case, just have linux-386-glibc2.0 and 
linux-386-glibc2.2 packages, etc.

> OK, but then you have done away with the one-size-fits-all approach.
> You cannot force someone to download every possible combination to
> install an app, so you are stuck again with system-specific packages.
> I'm not sure what you have gained with the new package system.

In this respect only (my proposal covers a lot more advantages than only 
this, but...), you would have (unix)-(platform)-(compiler) packages, not 
redhat packages and mandrake packages, etc.

> How is installing a Windows app better?  Each app just assumes the basic
> Windows dlls are there and installs everything else itself.  You can do
> that with rpms, too.  It just is inefficient not to reuse system
> components.

I was talking about ease of use.

> Not sure what about RPM makes this impossible.  If you install all
> libraries with RPM, it will know what's installed, and will let you know
> if something is missing.  Sure, you might wrap a nice GUI around RPM
> that, when something is missing, is smart enough to find out what and
> where you can get it.  But the fundamentals are all there IMHO.

In my opinion, RPMs are not expandable enough.  You couldn't add all the 
required functionality without breaking compatibility, in which case, you'd 
have a third format anyways, with the same extention.  Plus RedHat owns RPM.  
Wouldn't it be nice for a large group of all sorts of developers using all 
sorts of systems to develop xin's?

-- 
Casey Allen Shobe / ASI Technologies
cshobe@mediaone.net / cshobe@mailandnews.com
UIN: 1494523 / IRC: cshobe / AIM: shobe1knobe
Linux Echelon-Pro 2.4.0-test8 i686
-- 
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]