Hi,
I have asked in few past emails to the list about catalyst,
and finaly started to work with it. I did a lot of coding to overcome
problems with it. I created a script that can create spec files and
provide catalyst with the files to create stable or unstable trees.
I was asked by Peter Stuge what I would change in catalyst.
So here are my points:
1. improve the entry points for debugging. Sometimes you will need to
start from a certain point, when you debug stuff, so this will provide hooks
that are easy to use (commandline), and not the locking directory of the stage.
2. Solve some bugs or annoying things when working with catalyst, like
/usr/src/ is not created, or the glibc locals.
3. I already created a auto generator for spec files. This is the most
important bit
of the auto working of catalyst. It also auto generate stage4.spec.
4. take the fear out of the loop, and be agile to changes.
5. Documentation, hehe ;-) I really had hard time using this tool.
6. Minimal stage for embedded, that will be able to sustain releases
and freeze them
It should be implemented something like the crossdev tool, but in more
robust way. Also
using the ROOT= directive.
7. Crossdev integration.
8. Implement tiny portage tree (alredy implemented), but need to add
support for adding
packages to it as we go along. This keeps a really minimal subset
snapshot. It is really
good for small system, or compiling using tmpfs. I now have 8GB of
memory just for
the compilations.
9. auto creation of qemu image or image that implements grub,
partitions and few systems,
like debugging and compiling system, and the real embedded system.
10. sql + web frontend for people that really don't know gentoo.
11. Move to Ruby ;-) (but this is just a dream)
12. Make the code functional like C code, and no just big lump of
script (mostly in the Bash
scripts.)
13. It does look like this tool has grown from patch to patch under
fire (no time), so it needs
some change in the code, to be more understandable.
What I consider to do, is create a new catalyst tree, that will serve
as "next" tree for catalyst
stable. Though I'm still not sure that I'll hold myself not to
reorganize everything.
I understand that when Gentoo will have a good catalyst for users,
this will ease the work
of a lot of people, needing to use Gentoo in automated environments.
I also tried Metro, but found catalyst to work, and had hard time with Metro.
One needs to acknowledge that catalyst holds a lot of pearls in the
code, and this is its power.
My thoughts,
Kfir
I have asked in few past emails to the list about catalyst,
and finaly started to work with it. I did a lot of coding to overcome
problems with it. I created a script that can create spec files and
provide catalyst with the files to create stable or unstable trees.
I was asked by Peter Stuge what I would change in catalyst.
So here are my points:
1. improve the entry points for debugging. Sometimes you will need to
start from a certain point, when you debug stuff, so this will provide hooks
that are easy to use (commandline), and not the locking directory of the stage.
2. Solve some bugs or annoying things when working with catalyst, like
/usr/src/ is not created, or the glibc locals.
3. I already created a auto generator for spec files. This is the most
important bit
of the auto working of catalyst. It also auto generate stage4.spec.
4. take the fear out of the loop, and be agile to changes.
5. Documentation, hehe ;-) I really had hard time using this tool.
6. Minimal stage for embedded, that will be able to sustain releases
and freeze them
It should be implemented something like the crossdev tool, but in more
robust way. Also
using the ROOT= directive.
7. Crossdev integration.
8. Implement tiny portage tree (alredy implemented), but need to add
support for adding
packages to it as we go along. This keeps a really minimal subset
snapshot. It is really
good for small system, or compiling using tmpfs. I now have 8GB of
memory just for
the compilations.
9. auto creation of qemu image or image that implements grub,
partitions and few systems,
like debugging and compiling system, and the real embedded system.
10. sql + web frontend for people that really don't know gentoo.
11. Move to Ruby ;-) (but this is just a dream)
12. Make the code functional like C code, and no just big lump of
script (mostly in the Bash
scripts.)
13. It does look like this tool has grown from patch to patch under
fire (no time), so it needs
some change in the code, to be more understandable.
What I consider to do, is create a new catalyst tree, that will serve
as "next" tree for catalyst
stable. Though I'm still not sure that I'll hold myself not to
reorganize everything.
I understand that when Gentoo will have a good catalyst for users,
this will ease the work
of a lot of people, needing to use Gentoo in automated environments.
I also tried Metro, but found catalyst to work, and had hard time with Metro.
One needs to acknowledge that catalyst holds a lot of pearls in the
code, and this is its power.
My thoughts,
Kfir
