[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using bootstrap seeds write package definitions
Re: Using bootstrap seeds write package definitions
Tue, 18 May 2021 16:33:41 +0800
mu4e 1.4.15; emacs 27.2
Julien Lepiller writes:
> Hi c4droid,
> Le Sun, 16 May 2021 10:50:36 +0800,
> "c4droid" <firstname.lastname@example.org> a écrit :
>> Hello guix!
>> I was using the Linux From Scratch for a while as my mainly linux
>> distro, use soft link as package management. when I heard guix, I
>> think I found solution for my LFS package management. I tried guix
>> and guix system few month, Is time for switch my LFS package manager
>> to guix.
> I've been using LFS (and my own LFS-based "distro") for some years, so
> I completely understand why you'd want to use guix. Actually I based my
> "distro" on what I understood from Guix and the package manager from
> Haiku. When I understood I implemented that badly, I switched to Guix
> and Guix System entirely, no more LFS :D.
>> When I watched the manual talk about bootstrapping guix, I don't know
>> how to writing some package definitions with bootstrap-seeds, I was
>> searching on the google and ask questions on irc, because building
>> the LFS, want build the cross toolchain (stage 1) then build final
>> system (stage 2), last is kernel and initramfs (stage 3). after that
>> is build Beyond LFS (stage 4). I stuck with using bootstrap seeds
>> writing stage 1 package definitions. So I ask for help on community,
>> because the power of community is great. :)
> So Guix comes with a set of packages, which are just recipes to build
> them from source. There are two things you might want to do: you can
> either use the existing packages or create your own recipes for the
> whole system.
> If you choose to use our packages, then there are again two options.
> You can use the existing binary bootstrap (the only thing you wouldn't
> build yourself), or build it yourself and replace the binaries used in
> Guix by your own. Note that the bootstrap binaries are different from
> the binaries built for the first chroot of LFS (the cross-compiler). We
> do not use a binary GCC, but we instead start from mescc, a small C
> compiler, and use it to build tcc, then gcc, with the goal of reducing
> that down to stage0, which is only a few hundred bytes of binary, plus
> sources of other packages.
> # Using our recipes and bootstrap binaries
> If you want to use our bootstrap binaries, there is nothing to do,
> because Guix itself will be able to get the binary bootstrap and build
> everything from it. Do not enable substitutes if you want to build
> everything yourself.
> # Providing your own bootstrap binaries
> If you prefer to provide your own bootstrap, you'll have to build and
> provide binaries for the bootstrap seeds we currently have in Guix,
> that you see in the manual.
> # Building your own packages
> If you decide not to use our recipes, you must write your own. The set
> of packages is rooted in the bootstrap seeds, as you noticed. However,
> if you want to provide your own recipes, you are basically free to
> provide any bootstrap and further packages you want. What you could do
> is to build stage1 (cross toolchain), use that as your binary seed, and
> build the other stages as guix packages. Note that for that, you'll
> need to have guix already installed on the host system.
> If you have never used Guix, or never written a package definition, you
> might want to have a look at our short packaging tutorial at
> (French and German are also available if you prefer one of these
> There is some code in gnu/packages/bootstrap.scm that you might be
> interested in. It has some interesting bits: first there are a few
> binary seeds with hashes: they are statically linked binaries that are
> needed to decompress other seeds. Then, we define a few special
> procedures that replace the normal packaging procedures
> (bootstrap-origin, package-from-tarball). You probably want to use them
> or get inspiration from them to create your own bootstrap recipes
> (packages that simply decompress a tarball containing a prebuilt
> binary). The rest of the file lists these packages.
> Then gnu/packages/commencement.scm is the very beginning of the package
> graph. These packages use the binary seeds to build up to gcc, that we
> later use in the gnu-build-system, etc. You will be interested in the
> comments in this file too :)
I watched gnu/packages/bootstrap.scm and gnu/packages/commencement.scm,
I decide use mes tools and busybox utilities make bootstrap recipes and
my own bootstrap seeds, then follow the gnu/packages/commencement.scm
graph build cross toolchain and so on. But the way, the bootstrap and
commencement module give some inspiration for my idea.
> # My own experience with my package manager (not guix)
> If I recall correctly, what I did when I had my own "distro" (and
> package manager), is that I first built the cross-toolchain and base
> system from LFS (it was pre-10.0, and we built the cross-compiler and
> use it firts outside the chroot to build the base build toolchain we
> could then chroot to). I would first manually create a package from the
> chroot, and install a first system with only that package, then chroot
> to it. Then, from this system and the chroot package, I was able to
> build the base system with my package manager. Once I had the base LFS
> system (stage 2), that system had a dependency on the chroot package,
> which was not acceptable for me, so I replaced all the recipes to
> depend on the previously built version, turning stage2 into a set of
> bootstrap binaries. I rebuilt stage2 from the new bootstrap, and
> continued to write packages for other packages.
> Once I had my packages, I also wrote some code to create and install
> the initramfs and kernel (stage3).
> At this point, I could boot the new system, and continue with stage 4 :)
> Note that, in order to use Guix, you'll need Guix in the chroot
> package and all its dependencies, which is bigger than what LFS makes
> you build initially.
> Hope this is useful! Before I can help you further, I think I need to
> know which route you want to follow, as they are very different.
>> p.s.: Sorry for my poor english
> Hehe, don't worry. You can use your mother tongue if you prefer on this
> mailing list, although I can only help in English or French.
>> Best reguards c4droid