I'm am going back through 7.9 and using GNU stow for almost everything.
I'm building 7.9 for 3 pieces of hardware. x86_64, i686, and i586.  I'm
using 3 computers that match their targets.

I've successfully built is on all 3 and I've written scripts that allow me
to do it from start to finish.  In chapter 5 I added vim, stow, and busybox
static.  The later as more of a CYA.  I used stow to create the appropriate
links in /tools for the correct architecture.  I've got a full 7.9 with
100% stow. I'm a novice at package management so there may be problems with
what I'm doing.  I have a few questions for those that have done this.

1.  Coreutils.  What are the dangers of this?  De-stow can leave me with
nothing.  An upgrade of coreutils version would require a destow of the old
and stow of the new.  Below is a link to 50.sh (6.50) where I build it and
install it.  My idea was to use version info.
Another idea could be to use a busybox static with links in a special
directory and at package management time place that as the first path entry
in PATH. You'll notice in this script I'm using .stow-post-install.  Stow
needs pre,post,prep, etc support.


2.  Perl Modules.

I'm using the lib<module>-perl-X.XXX naming convention for modules.  All
perl modules added are added as an individual package.  Just like other
distros. 6.41 is XML-Parser-2.44.  That is stored in
/usr/pkg/libxml-parser-perl-2.44.  In my BLFS stage I have installed 122
Perl modules like this.  I do have to delete perllocal.pod for each one.

3.  folding vs no-folding.

I use no-folding almost all the time.  In #2 above I opted to fold perl
modules.  If I remove a module then directories created with no-folding
remain.  To support no-folding 100% I'd need a post-remove operation that
would look for directories that are part of the package and empty.  It
would then decide based on a set of rules to remove it.

Package management has already provided me benefit by making it easy to
replace vim7.4 with 8.0 that was released a few days ago.

FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to