[Fli4l_dev] Informationen zum Weekly-Tarball vom 4.7.2013 (r31452)

[Heinz-Peter Faasen]

Hallo Christoph,

> diesmal gibt es den Artikel etwas früher als sonst, weil ich morgen
> unterwegs bin ;-)

aha, Du wandelst auf Linus' Spuren. :-D

> FFL-872: Überarbeitung von provides/depends
> * Alle Pakete haben nun eine Versionsnummer, die unabhängig von der fli4l-
> Versionsnummer ist. Alle Pakete, die vorher keine solche Versionsnummer
> hatten, haben jetzt die Version 4.0.0. Bei künftigen Erweiterungen oder
> Änderungen wird die Versionsnummer erhöht werden. Das Ganze ermöglicht uns,
> Pakete eigenständig zu aktualisieren, ohne immer einen identischen
> Versionsstand über alle Pakete hinweg zu erzwingen. Mehr dazu siehe unten.

Tja, als ein Paket beim Build meldete, dass es Version 3.9.0 erwarte, 
die aktuelle aber 4.0.0 sei, dachte ich schon, ich hätte was verpasst. ;-)


> FFL-878: Update auf Kernel 3.15.3
> * Bitte KERNEL_VERSION entsprechend anpassen!

Läuft in der Virt-Version problemlos.

> --------------------------
> Neues Tarball-Build-System
> --------------------------
> Wir sind dabei, auf Grundlage der Continuous Integration-Software Jenkins
> (zu finden unter https://ssl.nettworks.org/ci/) unseren Archivbau neu zu
> strukturieren. Dazu gibt es experimentell unter
>
> http://fli4l.nettworks.org/tarballs/
>
> eine Web-Seite, von der alle Pakete, die in unserem Repository sind,
> heruntergeladen werden können, und zwar zu
> - jedem Entwicklungszweig (trunk, testing, FFL-506) und
> - jeder Architektur (x86, x86_64).
>
> Dies bietet allen, die ihre Installationsverzeichnisse nicht direkt aus
> einem SVN-Checkout bauen, die Möglichkeit, Änderungen zeitnah mitzubekommen.
> Wenn also eine Korrektur z.B. in dem ipv6-Paket nötig wird, weil jemand
> einen Bug in unserem Bug-Tracker gemeldet hat, dann werden die ipv6-
> Paketarchive sofort gebaut, sobald die Korrektur im Repository ist (und zwar
> die trunk-Archive). Hat das Team die Korrektur getestet und für gut
> befunden, wandert die Korrektur in den testing-Zweig, was zur umgehenden
> Anpassung der testing-Paketarchive führt. Man muss also nicht mehr unbedingt
> bis zum nächsten Freitag warten, wenn man gerne einen Bugfix hätte. Und
> jeder kann entscheiden, ob er Bleeding-Edge-Archive (trunk oder ein Feature-
> Zweig wie FFL-506) oder doch lieber etwas stabilere Archive (testing-Zweig)
> nutzen möchte.
>
> Auf der Web-Seite kann man auch "in die Vergangenheit" blättern, um ältere
> Tarballs herunterzuladen. Damit kann man testen, mit welcher Version ein
> Problem das erste Ml auftritt. Wie lange in die Vergangenheit das zukünftig
> gehen wird, steht noch nicht fest.
>
> Weiterhin kann man eine Menge von Paketen auswählen und dann in einem Rutsch
> herunterladen. Die Auswahl wird mit Hilfe eines Cookies gespeichert, so dass
> man die Auswahl nur einmal treffen muss (sofern man nicht zwischendurch den
> Rechner wechselt). Die so heruntergeladene Datei ist ein TAR-Archiv, das aus
> den ausgewählten Archiven besteht. Zusätzlich wird ein Skript extract.sh
> generiert, mit dessen Hilfe unter Linux-ähnlichen Systemen die Inhalte der
> Archive automatisch entpackt werden können (was man natürlich auch ohne
> dieses Skript manuell tun kann).
>
> Des Weiteren lassen sich alle aktuellen Paketarchive direkt per wget o.ä.
> unter
>
> http://fli4l.nettworks.org/tarballs/<Version>/<Zweig>/<Architektur>/
>
> also z.B.
>
> http://fli4l.nettworks.org/tarballs/3.9.0/testing/x86/
>
> herunterladen.
>
> Achtung: Die Paketarchive unterscheiden sich minimal von denen im
> wöchentlichen Tarball! Die Unterschiede sind:
> - Das base-Paket heißt "base" und nicht "fli4l-<Version>". Es hat auch nicht
> die zusätzliche Verzeichnisebene, die dem base-Paket sonst eigen ist.
> - Das doc-Paket heißt "doc" und nicht "fli4l-<Version>-doc".
> - Alle Pakete haben Versionsinformationen unterhalb version/<Paket>.txt.

Das liest sich alles sehr gut. Bin gespannt, ob es so klappt, wie es 
geplant ist.

> Der bisherige wöchentliche Tarball auf http://fli4l.de/ bleibt erst einmal
> weiterhin so, wie er ist. Eine mögliche Umstellung erfolgt erst, wenn das
> neue System sich bewährt hat.

Das heißt, es soll mittelfristig abgeschaltet werden?

> Rückmeldungen zu dem neuen Tarball-System sind natürlich gerne gesehen ;-)

Mache ich, sobald das Skript umgebaut ist.
Allerdings machen die Anpassungen inzw. fast mehr Arbeit als sie 
einsparen. Hoffentlich kommen die Umbauprozesse bald wieder etwas zur 
Ruhe. ;-)

> Viele Grüße und erfolgreiches Testen,

Vielen Dank für Eure/Deine Arbeit!
Heinz-Peter