Moving on

Thomas Krennwallner krennwallner at aon.at
Tue Jun 12 22:42:31 PDT 2001


Sorry for posting so late, but I slept a long time ;-)

On Tue Jun 12, 2001 at 11:20:17PM -0400, the boisterous
Gerard Beekmans <gerard at linuxfromscratch.org>
wrote to me:
> Can you tell RPM to read a configuration file (XML or whatever format)
> and then parse it and run commands based on it that compile a package
> and install it according to the instructions laid out in that file?

I think the choose for a xml-based file format is good, because as Bryan said
a month ago, that it could be used to create rpms/debs through a not coded
parser.

                / rpm
xml -> parser -
                \ deb

So the user has the chance to choose what he wants. I also think that we
should create an automatic rpm/deb install cd and a compile from scratch cd
(surely the user has to create them ;-).

> Why we choose XML? It's portable. There is a _lot_ of support for XML
> everywhere (perl, C, C++, Java, bash (well you'd need some help from awk
> and grep most likely, I think), Python, etc). It's relatively easy to
> create any kind of backend that reads XML and acts on it. Flexibility
> was a big reason for XML.

Thats it.

> > 1) What exactly is the goal of ALFS? Reading the website, I can't help but 
> > feel that this can all be done with RPM.
> 
> Perhaps my knowledge of RPM is too limited (so please do correct me) but
> I see RPM as a tool that unpack an rpm file and puts some files where
> they belong. I don't see RPM actually compiling from source according to
> a set of instructions.

Thats not true. rpm can create/unpack/delete/update/install/dependecies.
If you put a spec file into a tar.{gz,bz2}, you can create a rpm through simply
run rpm -ta bash-2.05.tar.gz, and then there is a
/usr/src/redhat/RPMS/i386/bash-2.05-1.i386.rpm
/usr/src/redhat/SRPMS/bash-2.05-1.src.rpm

So the whole ALFS stuff CAN be made with rpm, but why should we stuck on rpm,
when we have the chance to create a more general one which can be used to
create rpms/debs.

What I miss in the xmls is infos like license, descriptions, subpackages, and
so on. RPM is featurefuller than alfs-xml format. I also miss support for
installing in other directories and cross-compiling support (I hated it when
I recognized that a K6-2 cannot run i686 bins, but thats life).

> RPM forces you to have RPM installed on the system. XML forces you very
> little, other than _a_ kind of parser, be it a C program (nothing needed
> except a kernel), or perl, or java or bash. That way you just provide
> the xml profile (see it as a configuration file) and some kind of
> program to parse it (binary program or script language) and voila you
> get your LFS system.

Thats not true. rpm is a statically linked binary which uses those libs at
compile time:
bzip2, gzip, db and popt

If you use xml, it will always be a lib. An interpreter has much more
dependencies than rpm.

> > 3) How will XML help us attain what we want to attain? To me this is still a 
> > bunch of commands written in *sequential order*. How can XML be of any use?
> 
> Well yes of course sequential. If you don't install things in a certain
> sequence you don't end up with a working LFS system.

There should be some stuff like default configs in the xmls.

> Have a read through the ALFS archives if you want, there's a lot of info
> why we don't use rpm or similar approaches. I have voiced numerous times
> to actually support RPM. You can simply create an RPM database, based on
> what the XML profile/backend are going to install. But again we don't
> want to force RPM or DEB or any format. We provide plain text which
> opens a wide variety of backends and package managements (wants an mysql
> based package management? Could be a piece-of-cake)

Yup.

So my opinion on this thread is: make alfs-xmls more powerfull and create
a parser, so the user can decide to compile all stuff on installation or use
binaries with the prefered packager. This system could be very usefull for
sysadmins, who want to create install cds or for people who like to create
live-cds, which I want to put my effort in alfs development.

To put my opinion in the language war, I have to say:
Don't use C++, the ABI is not stable in the g++.
C is the thing, I use it to code everything (I'm a fulltime paid C programmer,
so I don't like C++, but please STOP all C++ flamewars, C++ has many 
advantages over C).

But for the xml stuff nothing is more right than a scripting language. We
use text for all stuff, and C/C++ is not designed to _easily_ write text
processing stuff. I prefer python, because of its clean design, but perl is
also good, as it's in default lfs.


What I also miss is default configurations like /etc/profile, ... That should
be a main reason to use ALFS.


And now new stuff: What do you think of xml based init scripts? Consider
something like this:

/etc/sysconfig/network
<network>
	<interface>
		<name>eth0</name>
		<address>192.168.1.1</address>
		<broadcast>192.168.1.255</broadcast>
		<netmask>255.255.255.0</netmask>
	</interface>
	<route>
		<destination>10.0.0.0</destination>
		<gw>0.0.0.0</gw>
		<netmask>255.255.255.0</netmask>
		<interface>wavelan0</interface>
	</route>
.
.
.
.
</network>


I hate all the sh-based config files, because they are all not proper designed,
every distro has other configs, ... they are simply not real configs. But
with this stuff, we have both the power of real config files and system
independance (ever created a system daemon and create init scripts for the
distros out there -> the hell).

OK, lets start, I want to hear your opinions ;-)

So long
Thomas

-- 
  ___    Obviously we do not want to leave zombies around.
_/___\     - W. Richard Stevens
 ( ^ >
 /   \   Thomas Krennwallner <krennwallner at aon dot at>
(__\/_)_ Fingerprint: 9484 D99D 2E1E 4E02 5446  DAD9 FF58 4E59 67A1 DA7B
-- 
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message



More information about the alfs-discuss mailing list