[gentoo-soc] Gentoo Anaconda Final Report

[gentoo-soc] Gentoo Anaconda Final Report

[wiktor w brodlo]

Hey Gentooers,


*Intro*

Gentoo Anaconda is a fork of Sabayon Anaconda which is a fork of
Fedora/Red Hat Anaconda. Anaconda is an installer for Linux disros,
originally for Fedora/RH but now it's distro-independent and many
other distros use it as their installer. Sabayon is a binary distro
based on Gentoo.

*Where are we?*
The installer can install a Gentoo and configure all the settings that
appear on the installer screens. The mirror support is still a little
buggy but not terribly so. The settings on the screens are the ones
included in the first part of the handbook, after the installer is
done you should reboot into a nice, basic but working Gentoo install.
It can also install xorg and a desktop environment, but it's still
unable to perform any additional actions that might be needed. This is
something I need to put some more work into, but since I don't know
all the environments that well, I'll need to talk to some people who
do before I can implement that.
Custom kernel support exists, and is in the code, but it's disabled as
it's not fully working (I did say on my original proposal that I can't
promise this one). Once I can polish it off, I will enable the
appropriate screen.

There is a bug in one of the packages that Anaconda depends on, which
can sometimes result in the installer hanging during the installation,
but I think the bug is in the ebuild. Since dependencies are not the
project itself, I don't consider this as an Anaconda bug.

*Where to go now?*
Overall, I feel that I've satisfied my original proposal of creating a
working, usable Gentoo installer. It's been fun but it's still a long
way to go before it can become a more official installer. I would like
to become a Gentoo developer so I can work on the installer further.
One of the first things I'd like to do is to write a proper,
interface-agnostic, installer backend, that the Anaconda installer, or
any other Gentoo installer will be able to use to query the available
options and run actions in a standard way. I would also like to write
a better error handling during the installation phase, as sometimes
packages fail to emerge for various reasons (failed to download, ran
out of memory etc., the usual stuff). I will also continue my
never-ending quest of slimming Anaconda down as there's still a lot of
dead/useless code in the tree (but figuring out what can go and what
should stay is a task on its own).

The source code is available in the Git repo, so are the installation
instructions. Details are available at
<http://soc.dev.gentoo.org/~wiktor/>.

Thanks to everyone, special thanks to my mentor Calchan and the releng
team for the awesome LiveDVDs that I keep spinning.

~ wiktor.

Re: [gentoo-soc] Gentoo Anaconda Final Report

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

On 23:00 Mon 22 Aug     , wiktor w brodlo wrote:
> I will also continue my never-ending quest of slimming Anaconda down 
> as there's still a lot of dead/useless code in the tree (but figuring 
> out what can go and what should stay is a task on its own).

Wiktor,

lxnay was kind enough to point out that removing "dead" code will make 
it extremely hard to rebase your work upon upstream changes. How do you 
propose to deal with that?

-- 
Thanks,
Donnie

Donnie Berkholz
Admin, Summer of Code
Gentoo Linux and X.Org
Blog: http://dberkholz.com


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-soc] Gentoo Anaconda Final Report

[wiktor w brodlo]

On 24 August 2011 04:16, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 23:00 Mon 22 Aug     , wiktor w brodlo wrote:
>> I will also continue my never-ending quest of slimming Anaconda down
>> as there's still a lot of dead/useless code in the tree (but figuring
>> out what can go and what should stay is a task on its own).
>
> Wiktor,
>
> lxnay was kind enough to point out that removing "dead" code will make
> it extremely hard to rebase your work upon upstream changes. How do you
> propose to deal with that?

Maybe not *extremely* hard. These days Anaconda development, both in
Fedora and in Sabayon, isn't exactly lightening-fast, so I think
following their development and merging back any nice changes
systematically won't take up too much time. I always thought that I'd
just keep their respective git repos locally and if there are any
changes, look at what they do and determine if they're of any use to
Gentoo. This way, only the changes done to the files that we also have
will be merged back in, and then only if they affect our installer -
for example, yum, Fedora repos, Entropy (Sabayon's package manager)
etc support is totally unneeded in Gentoo so there's no point even
bothering ourselves with changes to those parts, so I don't see any
point in keeping this code.

~ wiktor.

Re: [gentoo-soc] Gentoo Anaconda Final Report

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

On 12:07 Wed 24 Aug     , wiktor w brodlo wrote:
> On 24 August 2011 04:16, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > On 23:00 Mon 22 Aug     , wiktor w brodlo wrote:
> >> I will also continue my never-ending quest of slimming Anaconda down
> >> as there's still a lot of dead/useless code in the tree (but figuring
> >> out what can go and what should stay is a task on its own).
> >
> > Wiktor,
> >
> > lxnay was kind enough to point out that removing "dead" code will make
> > it extremely hard to rebase your work upon upstream changes. How do you
> > propose to deal with that?
> 
> Maybe not *extremely* hard. These days Anaconda development, both in
> Fedora and in Sabayon, isn't exactly lightening-fast, so I think
> following their development and merging back any nice changes
> systematically won't take up too much time. I always thought that I'd
> just keep their respective git repos locally and if there are any
> changes, look at what they do and determine if they're of any use to
> Gentoo. This way, only the changes done to the files that we also have
> will be merged back in, and then only if they affect our installer -
> for example, yum, Fedora repos, Entropy (Sabayon's package manager)
> etc support is totally unneeded in Gentoo so there's no point even
> bothering ourselves with changes to those parts, so I don't see any
> point in keeping this code.

You think manually inspecting all commits is worth it? Seems like `git 
pull --rebase` would be a lot easier.

--
Thanks,
Donnie

Donnie Berkholz
Admin, Summer of Code
Gentoo Linux and X.Org
Blog: http://dberkholz.com


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-soc] Gentoo Anaconda Final Report

[wiktor w brodlo]

On 24 August 2011 18:48, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 12:07 Wed 24 Aug     , wiktor w brodlo wrote:
>> On 24 August 2011 04:16, Donnie Berkholz <dberkholz@gentoo.org> wrote:
>> > On 23:00 Mon 22 Aug     , wiktor w brodlo wrote:
>> >> I will also continue my never-ending quest of slimming Anaconda down
>> >> as there's still a lot of dead/useless code in the tree (but figuring
>> >> out what can go and what should stay is a task on its own).
>> >
>> > Wiktor,
>> >
>> > lxnay was kind enough to point out that removing "dead" code will make
>> > it extremely hard to rebase your work upon upstream changes. How do you
>> > propose to deal with that?
>>
>> Maybe not *extremely* hard. These days Anaconda development, both in
>> Fedora and in Sabayon, isn't exactly lightening-fast, so I think
>> following their development and merging back any nice changes
>> systematically won't take up too much time. I always thought that I'd
>> just keep their respective git repos locally and if there are any
>> changes, look at what they do and determine if they're of any use to
>> Gentoo. This way, only the changes done to the files that we also have
>> will be merged back in, and then only if they affect our installer -
>> for example, yum, Fedora repos, Entropy (Sabayon's package manager)
>> etc support is totally unneeded in Gentoo so there's no point even
>> bothering ourselves with changes to those parts, so I don't see any
>> point in keeping this code.
>
> You think manually inspecting all commits is worth it? Seems like `git
> pull --rebase` would be a lot easier.

That would work too ;-)
Though having a look at the commits before the pull is a good idea by itself.