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

List:       kde-devel
Subject:    Re: starting to write a KDE auto-installer
From:       Meir Kriheli <mksoft () netvision ! net ! il>
Date:       2001-08-22 0:49:19
[Download RAW message or body]

On Wednesday 22 August 2001 00:38, Nick Betcher wrote:

Excuse me if I'm re-iterating but here goes:

I like apt a lot, and it installed KDE for me with no effort at all (had hell 
of a time doing the same on Mandrake. I'm also building from CVS on a 
LinuxFromScratch machine ), but I'm not sure it is the best solution for the 
auto-installer problem.

We need a solution that will work for different distros, OSs and CPUs. So why 
not take advantage of the source.

KDE has been a source distribution for a long time and the binaries were up 
to the packagers, so why do we want to change this ? We can elaborate on the 
current scheme.

Make the installer download the sources and rebuild KDE tailored to the 
target platform (file locations, compilers, apply needed patches to the 
sources if needed by the platform etc).

This well prevent us from storing and maintaining different binaries for the 
different platforms. What we need to maintain are the sources (we already do 
this) and the build specifications for the target platforms, which is much 
simpler, this will save allot of storage for the mirrors). 

The installer could also generate and leave binary packages in the target 
platform's native packaging format if there's a need to install in several 
machines to save the compile time on them (maybe this packages can be shared 
later - in something like freenet's' operation - the installer will have a 
binary proxy location - thus having the best of both worlds).

This can be expanded and instead of downloading the source, it can prompt the 
user for the stable release or the bleeding edge cvs release and get it from 
the cvs (but I'm not sure this would be a good idea - if the user can't 
install kde from source himself, should he be allowed to use cvs ? I don't 
know).

Something like the operation of : apt-get -b source ..... (but like I've said 
I'm not sure if apt is the correct way to go).

The installation process will be something like:

1. A shell script is downloaded and executed.
2. The script downloads the source for the installer and builds it.
3. The installer is executed and downloads the sources and platform specific 
files.
4. The installer builds and installs kde - possibly leaving native binary 
packages for further use.

-- 
Kriheli Meir

> How long did it take for Connectiva (or whoever did it) to port apt to rpm?
> I don't think I'm that prepared to side track and add support for other
> distributions in Apt. Once again, I rest my case with apt and hopefully
> everyone will see and understand that since I'm new to programming I can't
> re-write apt. Mabey if someone helped me, but of course I've "been there
> and done that".
>
> 				Thanks,
> 					Nick Betcher
>
> On Tuesday 21 August 2001 04:18 pm, Roberto Teixeira wrote:
> > Em Tuesday 21 August 2001 18:02, Nick Betcher escreveu:
> > > Hello everyone, me again.
> > >
> > > 	I see everyone making many points that I don't agree will work very
> > > well. Here is what I would like to point out:
> > >
> > > 	I plan to make this a stand a lone program. Not a frontend to apt or
> > > other such backends.
> >
> > IMHO one of the most important "features" of open source is code
> > reusability (btw, this used to be a hype word in the past). I think it
> > would be much wiser to build on top of an already proven technology. Apt
> > is a library and as such it can be integraded (and statically linked)
> > inside your programs. That's code reusability.
> >
> > > 	Apt is getting *way* too much attention here. I'll re-state my
> > > position on it again. Apt supports TWO packaging types. KDE is for Unix
> > > computers, not Debian and Mdk/RH specificly. I can't have half the
> > > program compensate for Slackware packages that don't have proper
> > > dependencies and then just turn around and let apt take over for Debian
> > > and Redhat. That isn't a very consistant program and would (possibly)
> > > favor *certain* distributions. I'm thinking about using KPackage if it
> > > supports more than RPM and Deb (can someone confirm this?). Please,
> > > everytime I talk about the installer all I hear is "apt, apt, apt".
> >
> > So I repeat. Use an already existing library (libapt) and change it. Port
> > it to support other kinds of packages. Apt used to be dep-specific until
> > we ported it to rpms.
> >
> > Still it is better to improve something that already exists and is used
> > by a lot of people than create Yet Another Installer(tm)
> >
> > On the other hand, Waldo's comments are very important. KDE does not
> > provide binary packages, instead it is the distributor's resposability to
> > provide with convenient ways to install/upgrade. That does not mean
> > someone should not create an installer (provided it is released under an
> > open source license) so that distributors might use it if it's better
> > than the original distribution mechanism.
> >
> > > 	Most of all I'm quite interested in the Ximian installer, but I've
> > > also heard about a lot of other programs from certain people. I'd like
> > > to hear more about other alternatives. What we REALLY need most of all
> > > is a library (not program) that can deal with many different types of
> > > packages. The more, the better.
> >
> > I don't think Red Carpet is the way to go. Red Carpet works because
> > Ximian has spent a lot of time (and possibly resources) into creating
> > official binary packages for a few specific distributions.
> >
> > I think everyone has the right to write their own installers from
> > scratch, but I think one may do a better job if standing on giant's
> > shoulders as someone put it a long time ago. :)
> >
> > Please consider building on top of Apt or some other existing technology.
> >
> > regards,
> >
> > 	Roberto.
> >
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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