faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: how about making upgrades easier
by sarang on Wednesday 11/Apr/2001, @00:10
|
>It is all up to what the author wanted to accomplish. If you wish to take advantage of a new feature then it's libs are required.
and the problem is that every developer has updated his/her machine to the latest and greatest KDE (even CVS probably as you suggest in the end). What about the users of the application? In simple english "you won't get next version of KMail unless you upgrade to KDE 2.2". Now suppose next version of KMail has "IMAP" as the new feature.. does it have anything to do with KDE 2.2? There could be millions of KDE 2.0.1 users our there.. and they'll never get KMail with IMAP unless they go through the pain of upgrading the entire KDE. Similarly with konqueror.. A lot of my friends still are on default LM7.2 which has KDE 2.0.1.. they keep complaining about Konqueror bugs which are fixed long time back.. but the problem is, konqueror is not released outside of KDE base packages.. hence to get latest konqi, full upgrade is needed!
>Here is all you need to upgrade. kdesupport, kdelibs and kdebase in that order. That also gives you konqueror. Kmail is in kdenetwork. That's far from all the packages.
why isn't konqueror seperate and developed individually? As I understand konqueror uses KParts (khtml etc.) to show the contents.. then why does teh konqueror code itself needs to be in the base libaries? Also, why isn't konqueror released periodically with latest and greatest khtml (since browsing is the main use of konqueror) which will upgrade the khtml the user installed with the KDE he/she has. Similarly, its clear that KMail is outside of KDE's base.. then why can't we have KMail released seperately just like Quanta, Aethera etc? On the other hand, the release schedules of konqueror, kmail etc. can be synchronized with those of KDE-base and we'll get the same effect as we get now.. i.e. KDE2.2 will come with KMail 1.4, konqueror 2.2 etc.. but people preferring to only upgrade KMail can do so too..
Now the question arises of new features.. to tackle that, KDE people definitely need to find a solution so that applications can automagically use the new feature of a newer KDE-base if it exists, else switch to old one. For eg., KDE 2.2 comes out with new printing.. there has to be some way so that KMail will automatically use this new printing scheme (read classes) instead of the old QPrinter if and when it finds teh new libraries installed. KDE has a lot of talended people and I am sure someone out there will be able to find a solution!
>If the io slave is built to your specification (and to my knowlege there has been no substantial change to the base architecture there for a while) then you DON"'T need to upgrade to make it work.
then why don't we get the latest and greatest cd ripping io-slave? why don't we have it for KDE 2.0.1 users?
>Pay attention. This will get you the la [snip]
You didn't get my point Eric. Let me first tell you that I am using KDE 2.1.1 on my LM 7.2.. I am pro in CS and have been using linux/unix for 4-5 years. I can very well download RPMS, install then and figure out problems myself. However, here, I am trying to solve the problem for newbies and even normal users or expert users who want to use linux for production purposes and not for playing with it. You cannot expect a corporation to upgarde KDE on all of its 1000s of machines every 2 months!
The solution of getting latest CVS and compiling is perfect for KDE developers themseleves.. but do you think of users?? Anybody who is doing productive work on his/her machine dosn't want to be on the CVS bleeding edge to have an unstable desktop!
> has far less problems than running RPMs.
this is plaing wrong. I have been using RPMs and never had any problems with them. The reason being I always use RPMs provided by Mandrake. Everything is perfect then.
Also, the whole point of KDE being user-friendly goes away when u ask u're users to compile!! its easy for devlopers and pros like us, but put u'reself in u're grandma's shoes and then think of it.. and if u dono't want to do that, then our motives are totally different!
Ok back to the main point.. some possible solutions:
-one solution to this seems to be major API changes be allowed only in distant releases. For eg. any application written for 2.0 - 2.1.1 should run w/o problems on 2.x.. this will ensure that atleast for 9 months u can afford to not upgrade ;)
-another is to provide backward compatible code.. for eg. provide KPrinter library for KDE 2.0 so that applications written for KDE 2.2 work with 2.0
-segregating base and apps can reduce this problem to a certain extent. Major KDE releases should be once a year with dates synchronized such that all applications that form KDE are released with these major upgrades. Minor upgrades could be frequent and should only include base library package upgrades. The application developers should make sure that applications run across the minor KDE revision. One advantage would be that it'll be easier for people to upgrade as they'll have to deal with fewer RPMs. Consider this: I have KDE 2.0.. new kmail comes out.. but they say I need to upgrade KDE-base packages coz it has new printing functionality.. so I go out and download 2-3 RPMs and upgrade my KDE base to 2.2.. then kmail installs peacefully and works perfectly. All other apps continue working as before since base libaries are always backward compatible (or rather should always be!!)
>I failed to imagine that people would begin bitching about it releasing too fast
I am not bitching.. I love the pace at which KDE is developing.. but that pace shouldn't kill it either right? If the user base decreases because of the tremendous confusion between releases and the pain to upgrade, then KDE will loose its following... which means Linux will loose its following.. and that shouldn't happen. Hence I am raising this issue here. Some how this entire development needs to be synchronized and some new solution has to come out to maximise the time between full upgrdes for people. One year life-cycle would be a good thing IMHO. You can expect people using linux to upgrade once a year.
Please guys, think of somethign cool to solve this issue.
I request someone who is on KDE lists to post on the lists so that KDE developers read this discussion and contribute. I am not subscribed so can't do that.
thanks!
sarang |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
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.
|
[
Reply To This | View ]
|
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 ]
|
|
Re: how about making upgrades easier
by Michael Häckel on Wednesday 11/Apr/2001, @04:53
|
Hi,
At least for KMail I can explain you why that is not possible. I even though about releasing a separarate version of KMail independant of the KDE release schedule when IMAP is ready for use, but that is no longer possible. Exactely because of IMAP there have been made a few additions to kdelibs to make implementing it much easier and now KMail of course depends on that changes. That is one of the advantages of keeping everything together. If an application needs a new feature in kdelibs this feature can be added and the application is immediately able to use it. Otherwise it would be every time necessary to wait for the next stable release and that would slow down development very much.
Regards,
Michael Häckel
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Naasking on Wednesday 11/Apr/2001, @12:16
|
Isn't this supposed to be the benefit of components though? You write components that can operate independently(and can co-operate) so you don't have to upgrade EVERYTHING to add one feature to your suite/app/whatever. You just have to upgrade the component which is dynamically loaded when needed. If the component wasn't there to begin with, it should be just a matter of installing it and having it registered with whatever service links the components with the services they provide.
Sure reuse, protection, network transparency are all cool component features too, but the main benefit of componentization is supposed to be complete separation of implementation from interface. If this isn't currently the case, then I'd say it's time to rethink the strategy behind the current component framework.
|
[
Reply To This | View ]
|
Re: how about making upgrades easier
by Alexander Kuit on Thursday 12/Apr/2001, @01:41
|
Wouldn't it be possible to create a statically linked version of KMail?
|
[
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)
