Rant: So you want help?

[Andrius da Costa Ribas]

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 <info at g-com.eu>:
> 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 at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows
>

-- 
Enviado do meu celular