Hi,
> I was not sure if it was the reason for the problems. Anyway i found
> out pankso is making his own cookutils. I'm temped to make a branch
> fork of it with my own changes. So they can be added when he pushed.
How did you find that ? You go in my $HOME ?
You are not nice to announce that like this without knowing my backend
idea.
I even have a web intreface:
http://people.slitaz.org/~pankso/cgi-bin/cooker.cgi
> There are alot of problems i have with it though:
--> And why I dont publish
--> You dont have the last version
> 1) mercurial sources are compressed as tar.bz2. We need to compress
> with tar.lzma to save on bandwidth and to be able to fit on to a dvd.
>
> 2) It looks like he is not recompressing the source tarball. This
> will make my livedvd pointless since it will be very big cause of
> this change.
The cook just repack hg|git|etc because it is not his job to recompress
source and because after that one can't just extract it graphicaly and
extra packages from a base flavor are neede to extract.
That said, my cook Handle *tar.lzma if exist and tazdev wich sync the
mirror will recompress, so you worl is NOT pointless.
> 3) We will need to add COOKOPTS option. It is used in packages like
> ruby-pkgconfig so .gem files are not extracted.
Exactly the kind of stuff you the only one to be aware...
> 4) It looks like you don't have gen cooklist or cook order yet. I
> hope this can get done.
You have, but not in cook. The cook is just a simple tool to cook
package and that all, it make log, check receip and build quality.
The cooker is the build bot:
* One utils: cooker
* 2 file for the web interface: cooker.cgi and style.css
The cooker will gen cooklist and can order a package list but the goal
is not to order 2960 packages and rebuild all SliTaz from scratch, if
you want to do so: USE TAZWOK
The cooker order fit in 100 lines and is appropriate for local daily
use and for Tank. The idea is simple: to much automation is crappy.
> 5) sources.list may need to be added at some point. Its to track what
> sources are incoming or in main. This way older sources are delete
> automatically.
Also we have that in tazdev from a while, you did not use it, it's you
choice. I think this is also the job of the sync tool not the build
tool.
> I know this is a incomplete version of your cookutils. But i would
> like to help before you make cookutils unusable for me and GoKhlaYeh.
I dont want to make it unusable, and want to use current receipt. But I
dont want feature to be add like that. It must stay a KISS tool, usable
by everyone easily, unbloated.
AND the cookutils will cook package but not do the all diner for you,
we need quality receipt and for speacial case, it is not to the build
tool to adapte it self, but to the receipt to be adapted.
> PS Don't be made for me posting this on the list. We have to be open
> about the new tools you are development. I don't want you to
> development something that no one in the community that may not like.
> And the last we need is slitaz to be forked.
... You and Gokhlayeh would have been the first knowing these tools
because effectively there will replace Tazwok on Tank, and I'm sure you
know why. Tazwok is no more a slitaz philosophy tools but a complex
Debian alike tool... Ok it's the only way to get a full system rebuild
from sratch and in one command. But this is not the need of Tank and
not the need of most SliTaz Developers.
Mayn people told me to revert, I dont want to, I respect your work and
dont want to loose you both as contributors. BUT please understand that
we need accessible build tools, that just work, easily debuggable and
that build tool a most important for a distro. Actually we try to fix
Tazwok for about 6 month...
That why I rewote a complet suite of tools from scrtatch and because in
the last years I also learned a lot and did'n want to include or reuse
old crappy code in the new cookutils.
- Christophe