On Fri, 18 Feb 2011 12:50:58 +0100 Christophe Lincoln <[email protected]> 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 <[email protected]> --- SliTaz GNU/Linux Mailing list - http://www.slitaz.org/
