faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: how about making upgrades easier
by Guillaume Laurent on Wednesday 11/Apr/2001, @00:51
|
> Now suppose next version of KMail has "IMAP" as the new feature.. does it have anything to do with KDE 2.2?
Yes. It could use new stuff from the base.
Look, what you suggest is completely unrealistic and would lead to total chaos in no time. Right now, upgrading KDE is very simple : download everything, recompile/install everything. That may take a long time, but it's still very simple. And most importantly it's simple to manage both from the developper and the user's point of view.
Compare this with schemes like "upgrade this package to this version and that package to that version if you need feature X in package Y" etc... By the time you figure out all the dependencies (which most of the time will end up being pretty close to "the whole shebang", you'd have downloaded everything already. Plus it would be a total nightmare for developpers and package builders. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: how about making upgrades easier
by Nathan on Wednesday 11/Apr/2001, @13:04
|
You're right, this is totally unrealistic. You can't expect to upgrade an application without upgrading all of its dependencies! This is why you can't upgrade Adobe Acrobat without buying a new copy of Windows, right? This is why you have to recompile all of Red Hat from source entirely every time you upgrade to a new version of KBiff, right?
Of course not! There is a huge time savings from only upgrading packages X,Y, and Z instead of the whole desktop. If I want a new KMail feature I shouldn't have to upgrade my entire desktop, possible breaking the configuration files for konqueror, knode, etc.
And "just" downloading everything and recompiling everything is a huge pain in the ass IMHO. I have yet to successfully compile KDE from start to finish without hitting all kinds of strange problems. This is *not* the solution if you really expect to be the "user-friendly" desktop that brings Linux to the masses.
It would be nice of the developers to at *least* document which config files are broken by new releases, letting the user know what kind of bumps to expect in the upgrade.
Sorry if I'm ranting, but I've spent *far* more time nursing KDE upgrades along than I ever spent rebooting my Windows machine. It's getting *very* frustrating.
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by not me on Wednesday 11/Apr/2001, @13:59
|
>And "just" downloading everything and recompiling everything is a huge pain in the ass IMHO. I have yet to successfully compile KDE from start to finish without hitting all kinds of strange problems.
I hear you! I've never been able to get KDE to compile.
>Sorry if I'm ranting, but I've spent *far* more time nursing KDE upgrades along than I ever spent rebooting my Windows machine.
Yeah, you sound like me, before I switched to Debian. Then suddenly, all my KDE problems magically went away. Now I get KDE upgrades *before* they've been announced on Slashdot, and they always install over the previous version perfectly, keeping all of my settings. I even have anti-aliased text in KDE, with _NO_ effort whatsoever! A simple command (apt-get install task-kde) finds, downloads, installs, and configures KDE _and_ all its dependencies, in one gigantic automated step! apt-get and kde.debian.net are the greatest!
Sorry if I sound like a broken record here, but I just can't get over the incredible coolness of apt-get. I recommend that you try Debian out (or for an easier graphical install, try that Progeny Debian that was just released).
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Guillaume Laurent on Thursday 12/Apr/2001, @01:08
|
Something like you describe will probably happen in the near future, but right now it's perfectly understandable that "everything" is just moving forward, from base to apps.
The base libs are bound to stabilize (API-wise, e.g. no new features) while the apps will keep on evolving. Right now it's just not the case, and maintaining two version of each app is a nightmare in the long range. They already do it between each minor releases (2.1 vs 2.2), but fortunately they try to keep it as short as possible, and limit the changes in the "old" branch to critical big fixes only. They don't backport new features and IMHO they are right in not doing so.
As for compiling KDE, for me it has always been "tar -xvf ; ./configure; make; make install". The only problems I've had are when I try to use --enable-final, which doesn't work for every packages. It's right though that config file are a serious problem. I had to clean up my ~/.kde several times after a new install.
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Ingo Klöcker on Thursday 12/Apr/2001, @07:48
|
>You're right, this is totally unrealistic. You can't expect to upgrade an application without upgrading all of its dependencies! This is why you can't upgrade Adobe Acrobat without buying a new copy of Windows, right?
Wrong example ;-) The right example would have been: You can't upgrade M$IE without upgrading a whole lot of the libraries which come with Windows. The only difference is that all new libraries you need are included in the installation package of the new IE whereas with KMail you also have to update kdelibs (because AFAIK some KMail related bugs have been fixed in some kio_slaves which are part of the libs) and maybe kdebase. But I think updating kdelibs could suffice.
If OTOH you use the packages provided by some distrubution you maybe have also to install the latest version of QT and some other libs this particular KDE build depends on. But for this the packager is too blame (was it really necessary to use the latest version of QT for this build?) and not the developers.
Regards,
Ingo
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
