[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:       Nick Betcher <nbetcher () usinternet ! com>
Date:       2001-08-21 21:38:27
[Download RAW message or body]

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

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