xml structures and some notes

Bryan Dumm bdumm at bobby.bcpub.com
Mon Sep 4 12:56:42 PDT 2000


Alfs Structures

Let's figure out the exact structures needed for LFS. Here are some
ideas and suggestions....

Logs
----
<logs>
dunno
</logs>


Enviroment
----------
<enviroment>
dunno but we have in LFS
$LFS
compiler flags
CPPFLAGS
PATH?
other?
</enviroment>

another <enviroment> example

<defaults>
   <target>/dev/hda5</target>
   <mountpoint>/mnt/lfs</mountpoint>
   <cflags>  -O3 -mcpu=i386 -march=i386</cflags>
   <cxxflags>-O3 -mcpu=i386 -march=i386</cxxflags>
   <tarballdir>/usr/src/tarballs</tarballdir>
</defaults>


Package
-------

Gerard submitting this one



Command
-------
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.....

<command>
        <name flags=p>mkdir</name>
        <arguments>/mnt/lfs</arguments>
</command>

<command>
        <name>cd</name>
        <arguments>$LFS/usr/share</arguments>
</command>

<command>
        <name>mount</name>
        <arguments>/dev/xxx</arguments>
        <arguments>/mnt/lfs</arguments>
</commands>


Jesse also sent me one that he found that looked
like

<command>
  <base name="/bin/mount">
    <boolean name="all" base="-a" default="false"/>
    <list name="options" delim="," base="-o "
values="exec|ro|rw|users"/>
    <scalar name="fstype" base="-t "
values="auto|iso9660|vfat|msdos|ext2|ntfs" default="ext2"/>
    <scalar name="special"/>
    <scalar name="mountpoint"/>
    <format>
      [all] fstype [options] special mountpoint
    </format>
  </base>
</command>



Init.d & config_files
---------------------
I think these make a lot of sense

<init.d_scripts>
        <name location=/etc/init.d>
        rcS
        </name>
        <data>
        #!/bin/sh
        # Begin /etc/init.d/rcS

        runlevel=S
        prevlevel=N
        umask 022
        export runlevel prevlevel

        trap ":" INT QUIT TSTP

        for i in /etc/rcS.d/S??*
        do
                [ ! -f  "$i" ] && continue;
                        $i start
        done

        # End /etc/init.d/rcS
        </data>
</init.d_scripts>


<config_files>
        <name location=/etc>
        group
        </name>
        <data>
        root:x:0:
        bin:x:1:
        sys:x:2:
        kmem:x:3:
        tty:x:4:
        uucp:x:5:
        daemon:x:6:
        floppy:x:7:
        disk:x:8:
        </data>
</config_files>

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?

Balu's Ideas
-----------
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)


LFS problems?
-------------

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
thinking..

Is Chroot a problem from a programming perspective? I know perl has a
chroot function.


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 
found in
/usr/bin. Since we moved it to /bin, the cache needs to be purged so bash can 
find
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 
nasties.

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 
I
had, but it seems evident that there is room for improvement here.


*BSD Ports Urls
---------------
http://www.netbsd.org/Documentation/software/packages.html

ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/Packages.txt

http://www.openpackages.org/

http://www.deadly.org/commentShow.php3?sid=20000816230547&pid=20

http://www.openbsd.org/ports.html

http://www.freebsd.com/ports/

XML Urls
--------
http://www.xml.com
http://www.xml-rpc.org

Neat xml application....
http://www.jabber.org







More information about the alfs-discuss mailing list