A "default" flow and an "Advanced..." button on the installer can solve the problems some people here are pointing (altough I don't see it as a problem at all). I have something else in mind... but I'm not sure if it is a good idea or an unreachable reverie, here it is: - having an installer for the core components (kdelibs etc..) - having a port of kpackagekit with a packagekit backend based in our text-based installer (or even emerge) - kpackagekit would be also got from the "core" installer. - "channels" could then be configurable, in a similar way of apt's sources.list, then when a release has not all of its packages it would lie on "incomplete" channel, so it would be easier to package in a collaborative way, as opposite to currently having to package everything at once for one release. A regular channel would be provided for end-users. This would also facilitate adding third-party apps and libs. I hadn't looked at packagekit's source yet so I have no idea if it is easy or impossible to port (I've only seen we'd need a dummy polkit) but maybe this can make other ideas appear :) - maybe it's time to brainstorm (typing from mobile is horrible :( ) 2010/11/5, Alf Gaida : > Am Samstag 06 November 2010, 00:18:28 schrieb Ralf Habacker: >> Am 5.11.2010 18:57, schrieb Thomas Friedrichsmeier: >> > On Friday 05 November 2010, Patrick Spendrin wrote: >> >> Well, making a restriction in the installer is the first task. The >> >> sources for the installer are in trunk/kdesupport/kdewin-installer - it >> >> is normal Qt application ;-) >> > >> > Alright, I'll take that as a go-ahead and start looking into it. >> >> Are you aware that adding an additional executable with mostly the same >> functionality may result into more problems than to solve ? >> >> There is a concept that the last recent installer is always named >> kdewin-installer-latest.exe. The url of this installer is spread all >> around the world, has been linked into many websites and is downloaded >> up to 100000 times a month. When this option is removed from the >> installer and for each compiler a different url is provided, who is >> going to talk with all those website maintainers to add additionals link >> in case more than one compiler is supported. >> Or if only one compiler is supported, who will explain users 10 times a >> day, why compiler xyz isn't available anymore. Having all this >> possibilities in one installer makes it able to change installers >> behavior from release to release without any broken links and increased >> support requests by this. >> >> In the opposite there is the single installer approach with a minimal >> gui approach, see >> http://www.winkde.org/pub/kde/ports/win32/setup/stable/ - but in both >> case some people are not satisfied. >> >> Ralf >> >> _______________________________________________ >> Kde-windows mailing list >> Kde-windows@kde.org >> https://mail.kde.org/mailman/listinfo/kde-windows > > It may be hard, but _if_ this would be the final descision it can be > communicated before the new release is done. Breaking the old installer can > be > communicated as a new start for KDE for Windows. Some people have to fix > some > links, so what. The first hours could be hard for the bugtracker, but if the > new behaviour is also in the bugtracker before, where is the problem. > > Its all about communication. > _______________________________________________ > Kde-windows mailing list > Kde-windows@kde.org > https://mail.kde.org/mailman/listinfo/kde-windows > -- Enviado do meu celular _______________________________________________ Kde-windows mailing list Kde-windows@kde.org https://mail.kde.org/mailman/listinfo/kde-windows