[lfs-support] Packaged LFS-6.8

Bruce Dubbs bruce.dubbs at gmail.com
Fri Aug 24 10:10:07 PDT 2012


Baho Utot wrote:
> On 08/24/2012 11:50 AM, Bruce Dubbs wrote:
>> Baho Utot wrote:
>>> I have successfully packaged LFS-6.8 using pacman from arch linux.
>>>
>>> Here is the link if anyone is interested and wants to have a look.
>>>
>>> https://github.com/baho-utot/LFS-pacman
>>>
>>> I am going to update that repository to versions 7.0 7.1 and 7.2.
>>>
>>> The "build system" I use for the tool chain chapter 5 could be adapted
>>> to the base chapter 6.
>>> I think it is a easy way to script a build.
>> I think everyone should build at least one version of LFS manually.
>
> I do too,
>
>>
>> That said, what does pacman offer over jhalfs?
>
> I had some trouble with jhalfs a long while ago. LFS-6.3 I think. I was
> MIA with LFS from 6.3 to 7.0 ;)
>
> Anyway......
>
> I needed a package manager so I can build once and install everywhere,
> which is what pacman gives you.
> One has a central/group repositories so updates to an existing boxs can
> be done easily.
>
> To install a new box all you need to do is to boot a live cd to
> partition the drive(s) then,
>
> install -vdm 755 /mnt/var/lib/pacman
> install -vdm 755 /mnt/var/cache/pacman/pkg
> pacman -Syy -r /mnt
> pacman -S base --cachedir /mnt/var/cache/pacman/pkg -r /mnt
>
> then configure /etc/fstab etc, install grub and your done.
>
> If you don't need a build once and install everywhere then the only
> other benefit is building in a controlled environment and then you can
> query the package to give you the dependencies that the package needs.
> It also helps you keep unwanted dependencies from creeping in. For
> example if you build on a host that has everything but the kitchen sink
> and then try to use that package on another box it won't work because
> the other box may no have all the dependencies installed there. by
> building in a chrooted environment you control the dependencies.
>
> Pacman also makes it easy to test new packages by allowing you to
> uninstall completely a package, the only thing left over will be files
> the package creates itself. Those you can find by running the
> pacman-disowned.sh script and anything not "owned" by the package
> manager is logged. Then you can deal with the log as needed.
>
> Another example you can down grade packages so it you install a new
> systemd/udev and it don't work you can fix that by downgrading to the
> previous package.
>
> The bottom line is pacman will give me a way to "create" a LFS distro
> that I can maintain and spread to all the boxs I admin. I won't be stuck
> with the ah hem commercial distros, systemd etc. So LFS plus pacman is a
> big win for me.

OK, I can see where some would think that useful, especially for the 
BLFS packages.

For LFS, I generally just create a tarball of the lfs built system and 
extract that into a blank partition.  If the devices are different, I'll 
need to rebuild the kernel, but generally things go well.  Of course 
there are a few configuration files to update /etc/fstab, 
/etc/sysconfig/ifconfig.eth0, and /etc/sysconfig/rc.site.  Perhaps the 
/etc/hosts file needs to be updated too.

Generally there are also a few configuration files I pre-place before 
creating the tarball: dircolors, inputrc, vimrc, profile.d, etc. 
Finally there are also a few files that I always build from BLFS before 
creating the tarball, notably ssh.

   -- Bruce






More information about the lfs-support mailing list