Re: Wok and packages status

[GoKhlaYeh <gokhlayeh@xxxxxxxxxx>]

On Fri, 18 Feb 2011 12:50:58 +0100
Christophe Lincoln <pankso@xxxxxxxxxx> wrote:

> To setup current tazbb and chroot environment I did:
> 
> # tazpkg get-install slitaz-dev-tools tazbb
> # tazdev gen-chroot
> # tazdev chroot
> # tazpkg get-install tazbb mercurial
> # cd /home/slitaz/hg && hg clone http://hg.slitaz.org/wok
> # tazbb cook-all
> 
> Please make experimental tools a bit easier :-)

You can't compare theses two situation; the equivalent of what you wrote
is setup chroot + cook all, but there's **no experimental tools into
stable environnment**, so you can't tazpkg get-install any of them:
you need an experimental environmnent first. So, it's not about
experimental tool anyway, but about setting up an experimental
environment...

That said, I'm preparing a package for thoses who want to use
experimental from another version of slitaz. It will be
easier to use, so harder to understand :)

> That said I'm not sure we need to rebuild toolchain each time since
> package are build on the same host with the same libs.

Using LFS method, we have to rebuild the toolchain if we want to update
core-toolchain packages (linux-api-headers/binutils/glibc/gcc). And, I
think, to recook-all next. It ensure consistency:

"If one of the toolchain packages (Glibc, GCC or Binutils) needs to be
upgraded to a newer minor version, it is safer to rebuild LFS. Though
you may be able to get by rebuilding all the packages in their
dependency order, we do not recommend it. For example, if glibc-2.2.x
needs to be updated to glibc-2.3.x, it is safer to rebuild. For micro
version updates, a simple reinstallation usually works, but is not
guaranteed. For example, upgrading from glibc-2.3.4 to glibc-2.3.5 will
not usually cause any problems. "
Source:
http://www.linuxfromscratch.org/lfs/view/development/chapter06/pkgmgt.html

I add linux-api-headers to this as experience prove that upgrading
linux-api-headers can make some packages uncompilable (it's better to
recook to check all is fine).

An idea beyond tazwok-experimental is : recook all reverse-depends if
it's needed, and check all cook fine before pushing packages from
incoming (packages-incoming) to main (packages) repository. It's
also because I plan to add a feature which pack a .tar.lzma wok
containing receipts used to cook main packages - it means thoses known
to compile well - to propose to users using compilation upgrade method
a safe wok.

Even micro update in core toolchain can include stuff which screw things
- and need some fix added to some receipts -, so if you recook only one
of the core-toolchain package you can screw cook process for several
packages but you can't know it (as you don't recook all). The
consequence is you think all is fine but if someone else try to cook
wok from scratch it will fails.

As I explained in previous mail,  nothing is build against host:
toolchain is builded against itself, and all packages against
toolchain.

> [..] But when we
> rebuild everything from sratch is better to build all base-package once
> and then rebuild them a second time.

The LFS method ensure consistency by compiling the core toolchain
against itself: theses packages doesn't needs to be cooked a second
time. The non-core toolchain (other than
linux-api-headers/glibx/binutils/gcc and their depends), and only them,
should be cooked a second time (when re-cooking all from scratch);
technically it's not always needed: it depends on which packages you
put in toolchain, so I put this recook rules quite arbritrary because
it's ensure all will be fine regardless which packages you putted into
the toolchain.

Most knowledge I have about cooking a toolchain (and a system from
scratch) comes from the LFS book:
http://www.linuxfromscratch.org/lfs/view/development/
and from experimentation (I think I cooked the toolchain at least 20
times during the cook-toolchain coding and thousands of packages).

I also red some threads about toolchain compilation and various method
used in other distros. I get some information from Gentoo forum,
particulary this one and related:
http://forums.gentoo.org/viewtopic-t-282474.html

It shows how upgrading the toolchain can be a pain if not all is
recooked in right order; In the case of gccc 3.4.3 it was a micro
update but a full recook was required to take advantage of this update.
I choosed to use a method wich don't comes with drawbacks I described
and allow that everybody can cook SliTaz from scratch at home, in a way
that ensure there will no be more breakage or inconsistencies. Even if
not always required, I think we should follow this method on tank as
it's not an user system, it's everybodies system: be safe from
failure as possible is a good idea :)

-- 
GoKhlaYeh <gokhlayeh@xxxxxxxxxx>


---
SliTaz GNU/Linux Mailing list - http://www.slitaz.org/