[Hamara-devel] Can we use Something like Ubiquity for Hamara sugam

[shirish]

at bottom :-

On Wednesday 19 August 2015 06:07 PM, Vikas Tara wrote:
> On 19/08/15 12:48, Raju DV wrote:
>>
>> On मंगळवार 18 ऑगस्ट 2015 09:06 म.नं., shirish wrote:
>>> In-line :-
>>>
>>> On Tuesday 18 August 2015 04:16 PM, Raju DV wrote:
>>>
>>> <snipped>
>>>
>>>> I just found this great alternative to Debian Installer
>>>> Calamares,
>>>> https://calamares.io/
>>> Had seen it before, looks good . The only issue I had before and still
>>> do is it uses KDE components/libraries for partitioning :-
>>>
>>> See the partitioning modules, all of them are KDE components/libraries.
>>>
>>> I did see that there are almost 28 people who have forked it, see if
>>> there is somebody who has instead used the GTK+ toolkit. That is the
>>> toolkit that LXDE, MATE, GNOME and XFCE uses so if we are able to use
>>> the gtk toolkit, we support out of box two desktop environments and have
>>> two more targets that we could easily achieve if we want to in the near
>>> future. I *think* this is the reason it doesn't seem to have a major
>>> take-up till date.
>>
>> Some of the distributions who are using Gnome are also using calamares,
>> and one of them Tanglu (tanglu.org) is directly based on Debian.
>>
>> There code is also available on https://github.com/tanglu-org which will
>> be useful.
>>
>> So support for GTK+ is there and can be worked upon.
> Looks interesting - but why wouldn't we fix problems with d-i itself?
>
> Also - I don't think gtk support is really that important - it's not
> like the installer is going to stay on the system beyond the
> installation time.
>
> If we did want to make a jump to Calamares - I don't see an issue using
> it's kde components.
>
> Perhaps we should discuss ubiquity vs calamares.
>
> Shame that most of the recent sugam work has been centred around moving
> from ubiquity to d-i :)
>
>

In that case, go ahead.

I did do a preliminary checkout and tried to use debhelper clean (force 
of habit :) ).

As I do not have any KDE development packages, it said the same.

dh clean --dbg-package=calamares-dbg --with kf5 --parallel
dh: unable to load addon kf5: Can't locate 
Debian/Debhelper/Sequence/kf5.pm in @INC (you may need to install the 
Debian::Debhelper::Sequence::kf5 module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 
/usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 
/usr/local/lib/site_perl .) at (eval 11) line 2.
BEGIN failed--compilation aborted at (eval 11) line 2.

debian/rules:6: recipe for target 'clean' failed
make: *** [clean] Error 2

Hopefully you will be able to share with development packages are needed 
in debian to compile it properly.

Also if you remember D-I has this concept of udebs (deb packages 
specially packaged for the installer) .

udebs are same as .deb minus the whole /usr/share/doc bit and other things.

See https://d-i.alioth.debian.org/doc/internals/ch03.html for more.

AFAIK most of the what debian developers/maintainers do, they 
make/compile two packages, They make a .udeb as well as makes a regular 
.deb file as well so that people know what new changes have come.

But this does not happen for all files as it's not needed. For instance, 
partman has no business after installation, localization files for 
installation and few other packages.

Any idea how calamares uses udeb or what other ways it achieves the same 
thing ?

If it uses or has support for udeb then we would not have to learn 
anything new or exotic and just re-use the same knowledge that we were 
using for d-i.


Look forward to knowing about calamares.
-- 
Regards,
Shirish Agarwal,
Community Lead,
Hamaralinux.org