xml structures and some notes
bdumm at bobby.bcpub.com
Mon Sep 4 12:56:42 PDT 2000
Let's figure out the exact structures needed for LFS. Here are some
ideas and suggestions....
dunno but we have in LFS
another <enviroment> example
<cflags> -O3 -mcpu=i386 -march=i386</cflags>
<cxxflags>-O3 -mcpu=i386 -march=i386</cxxflags>
Gerard submitting this one
On <command> I left <command> instead of
using <cp></cp>,<mkdir></mkdir> because
I think it is better if we leave it in
<command> and name command like below.
This leaves command under one category
instead of a whole bunch.....
Jesse also sent me one that he found that looked
<boolean name="all" base="-a" default="false"/>
<list name="options" delim="," base="-o "
<scalar name="fstype" base="-t "
[all] fstype [options] special mountpoint
Init.d & config_files
I think these make a lot of sense
# Begin /etc/init.d/rcS
export runlevel prevlevel
trap ":" INT QUIT TSTP
for i in /etc/rcS.d/S??*
[ ! -f "$i" ] && continue;
# End /etc/init.d/rcS
On the more than one group issue or even on the
what do you do when you got a config_files and the
config file already exists problem, I think it
should be left up to the backend to do with it as
appropriate, maybe write some general(config_file)
guidelines. Putting those issues in the xml structure
would be confusing wouldn't it?
A tag that makes it possible to ask the user something would be great
(where do you want to install the LFS?)
What would this look like?
<input>Your question here</input>
And - wouldn't it be great to have some kind of tags to add descriptions
in a way that you can create an install-chapter using ALFS? ;)
(not sure what you mean exactly)
These are things I have noticed in LFS that might present problems
on gcc, glibc extras? or how to determine what to do, + make bootstrap(?)
on glibc I saw Country= somewhere(actually US=yes) but we can use something
similiar for those issues
Should we have a license tag, ie license=gpl-only?
How do we do the kernel stage?
MakeDev and /dev in general
maybe not a defined structure but something from gerard's suggestions
on how to use the packages during the build process, ie. where to store,
how to start over, etc. some general programming guidelines is what I am
Is Chroot a problem from a programming perspective? I know perl has a
LDso - how else can this be done?
The "hash -r" command is to make bash forget about the locations of previously
executed commands. If you have executed ldd before, bash expects it to be
/usr/bin. Since we moved it to /bin, the cache needs to be purged so bash can
it in /bin when you want to execute it again.
NetBSD ports list
I saw these on the netbsd ports list. We have to think
about such things before we get down these roads...
The problem I'm trying to solve, is that binary package users are
presently forced to upgrade in the same order as the binary package
builders. It's clearly a flaw in the system that, for instance, to
upgrade from png-1.07 to 1.08 you must deinstall half a dozen
packages, even though you may then reinstall the _exact_ _same_ binary
packages, which have the _exact_ _same_ binaries.
I'm comfortable with the fact that, in the general case, the package
builder has to build the dependencies in order, but I think we can do
better for binary package users
As impressed as I am with how FreeBSD handles apps, there is one aspect I
fealt wasn't quite as strong as rpm.
rpm's provide a fairly elegant method of udgrading applications that appears
to deal with the issues of cleaning
out the old app and getting the new one in there. FBSD on the other hand has
you go with a process of
deinstalling then reinstalling which seems to be prone to all kinds of
For example, when trying to deinstall a library that other apps depend on the
system will stop ya in your
tracks. Just trying to install over an older app puts both versions into the
database. I'm still fighting a wrong turn I made when upgrading XFree86. I'm
certain that a more experienced user would have danced right around the probs
had, but it seems evident that there is room for improvement here.
*BSD Ports Urls
Neat xml application....
More information about the alfs-discuss