[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Paketvarianten (gentoo alike)



* Jonathan Dumke <jd@bepe.de> schrieb:

Hi,

> Jetzt beginne ich langsam zu verstehen, wo die Reise hingehen soll.
> Das einzige Verständnisproblem, welches ich noch habe bezieht sich auf 
> das Wort "modelliert". Was meinst du konkret damit, eventuell etwas in 
> der Form:
> Switch	 Wert		gwählte Optionen
> Gui	off		--disable-curses, --disable-gt-gui, ...
> Gui 	curses		--enable-curses,  --disable-gt-gui, ...
> etc.

Sowas in der Art.
Beim meinem Briegel sieht das zB. für coreutils so aus: (Ausschnitt)

feature:        threads
off:            --disable-threads
--
feature:        acl
on:             --enable-acl
off:            --disable-acl
--
feature:        assert
on:             --enable-assert
off:            --disable-assert
--
feature:        largefile
on:             --enable-largefile
off:            --disable-largefile
--
...


> Also das ein Schalter, je nach Wert, verschiedene Optionesketten wählen 
> kann, oder etwa doch anders.
> Dies liese sich durchaus über die vorgeschlagene Skript-Lösung 
> realisieren. Die von dir angestrebte Vereinheitlichung --jedes Paket 
> Paket braucht jedoch sein eigenes Skript-- könnte man eventuell mit 
> einem Debhelper-Skript umsetzen, das beispielsweise den Namen 
> dh-mkoptionconfig tragen könnte.
> 
> Trifft dies deine Assoziationen eher, Enrico?

Jep. Ich würde sogar eher dazu tendieren, die Debian-buildscripts
automatisch aus der abstrakten Beschreibung generieren.

IMHO ist die Mächtigkeit der Buildscripts (Turing-Vollständigkeit ;-o)
völlig überflüssig, sofern man bereit ist, ggf. den Sourcecode
etwas mehr anzufassen. Briegel ist so aufgebaut, daß es mehrere
linear aufeinander folgende Stages gibt:

    1. prepare-sysroot:
	hier wird das sysroot image vorbereitet, dh. alle Abhängigkeiten
	dort rein installiert (und ja: sysroot ist bei Briegel eine
	Primärvorraussetzung ;-p)

    2. prepare-sourcetree:
	sourcetree holen/entpacken/patchen (deprecated) oder direkt
	via git ziehen

    3. preconfigure:
	autoconf / automake, etc (idR. autogen.sh call)

    4. configure
	das übliche configure commando (oder ähnliches)

    5. build
	idR. make cal

    6. install
	idR. make DESTDIR=... install

    7. package
	aktuell einfach nur einen tarball vom install image
	(sollen später auch diverse Paketmanager wie dpkg oder rpm
	eingebaut werden)

Das ganze wird configuriert über einfache property lists mit einer
trivialen Variablen-Ersetzung. Es gibt dazu eine Reihe "styles",
die das allermeiste vordefinieren (teils aus der target-config,
teils aus der package-config referenziert), sodaß für die
individuellen Pakete nur ganz wenig beschrieben werden muß.


Wenn mir mal etwas mehr Freizeit vergönnt ist, werde ich auch eine
direkte Debian-Paketierung dazu bauen (einerseits .deb's erzeugen,
andererseits auch für das Sysroot-Image installieren).


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------


Reply to: