Idee: VDR für alle durch weitere Standartisierung und Updates via Internet

Ich denke dass es eher die Frage ist, ob man ein stabiles Produktiysystem über Jahre ohne Updates will *oder* eben ein System was ständig upgedated wird.

Updates UND Stabilität setzt eben voraus, dass die Rahmenbedingungen alle kennt:

- alle Konfigurationsdateien
- alle Systempfade
- Kernelversionen und -konfiguration
- Treiberversionen
- Distribution und aktuellen Update Stand

Ich denke das lässt sich nur machen wenn sich einige Leute um eine spezielle Distri kümmern und viel Arbeit investieren. Und das gibts doch schon.

Zitat

Original von wirbel
Ich denke das lässt sich nur machen wenn sich einige Leute um eine spezielle Distri kümmern und viel Arbeit investieren. Und das gibts doch schon.

Man müßte den VDR samt Konfiguration auf eine Meta-Ebene schieben, die für alle Distributionen gleich ist. Die Verbindung zu zur Betriebssystem erledigt dann der VDAL (VDR Distribution Abtraction Layer)
Die VDR Meta-Ebene könnnte man versionieren und dann stabil laufende Konfigurationen 'stempeln' .Diese können dann bei Bedarf wieder hergestellt werden.

Zitat

- alle Konfigurationsdateien
- alle Systempfade
- Kernelversionen und -konfiguration
- Treiberversionen
- Distribution und aktuellen Update Stand

Alles anzeigen

ähm das kennt man eh alles... ein vernünftiger kernel sagt dir auch was er alles drinnen hat...

treiberversionen ebenfalls...

im übrigen sind das wirklich nur "kleinigkeiten" die da probleme machen könnten und das würde sich ohne probleme mit scripts in den griff bekommen lassen...
naja anscheinend bin ich hier der einzige der mit einem unverpatchten vdr wunderbar zufrieden ist und deshalb keine probes beim installieren kennt...

73

Kennst du das wirklich? Nur wenn du weißt was genau für ne Distri das ist.

Das Thema Binaries ist - wenn ich beim Überfliegen des Threads richtig gesehen habe - schon vom Tisch , weil nur mit Beschränkung auf i386er Code oder extremem Aufwand realisierbar - nicht wirklich sinnig .

Um Abhängigkeiten zu libs vorzubeugen wäre ein Weg , das Ganze statisch zu compilieren - was allerdings nicht jede Source zuläßt und den Platzbedarf hochfährt .

Generell erscheint mir die Forderung "aktuell" und "rockstable" nicht vereinbar zu sein .

Ein Kompromiß ist durchaus - wie schon im Thread angemerkt - durch Scripte zu erzielen .

Allerdings würde ich dabei nicht den Weg gehen , auf sämtliche Distries einzugehen und zu checken .

Wenn jemand eine Struktur empfehlen könnte/sollte , so ist das wohl Klaus .

Generell dürfte es aber doch den Binaries egal sein , welches Script aus welchem Verzeichnis sie startet - das aktualisieren bezieht sich ja i.d.R. auf die Binaries selbst .

Hier ist es dann ja durchaus machbar , durch Scripte die der geneigte User in einem Setup auswählen kann ( er wählt natürlich keine Scripte , sondern Packages ) das Builden der Binaries zu realisieren .
Abhängigkeiten zu ner libc oder Linker sind nicht relevant , da die Binaries ja mit der vorhandenen libc/ld gebuildet werden .

Das jeweilige Buildscript kann Abhängigkeiten checken und ggf Sourcen nachziehen und builden .

Am Rande bemerkt , ist es genau das , was die hjslfs Scripte machen , mit der Spezialisierung , daß gebuildete und damit installierte Packages nicht durch Existenz in /usr / lib oder /bin ermittelt werden , sondern durch durch eine Datei , die durch das Buildscript in /var erzeugt wird .

Nichtsdestotrotz läßt sich aus meiner Sicht die Forderung aktuell/rockstable nur mit einem Dev und einem Produktiv System erfüllen - Materialaufwand .

HJS

Hallo,

ich beschaeftige mich seit nicht allzulanger Zeit mit diesem Problem, und bin auf ein Buildsystem umgestiegen, das sich an der Struktur der init runlevel Scripte orientiert.
Fuer ein einzelnes "globalgalaktisches" konfigurierbares Buildsystem ist die Vielfalt an Optionen und Konfigurationsmoeglichkeiten viel zu gross, und die verschiedenen Umgebungen tun das Ihre dazu die Sachen weiter zu verkomplizieren.

So entstand folgende Idee:
Es gibt ein 'Master' Script, dass die package-Scripte aufruft
Es gibt 'package' Scripte die ein Package oder Feature dem build hinzufuegen.
Jedes Package Script wird mit den Argumenten 'prep' 'install' 'config' aufgerufen.
- prep bereitet das Paket vor.
- install installiert zugehoerige scripte,conf-files,etc.
- conf erzeugt ein config file das zum starten des plugins/features benutzt werden kann
Nicht jedes Script muss alle der obigen Funktionen nutzen.
Jedes Package Script beginnt mit einer Nummer und die Scripte werden in aufsteigender Reihenfolge ausgefuehrt.

Das Master Script fuehrt jedes Package Script mit dem 'prep' Argument aus, danach wird im VDR Verzeichniss 'make' und 'make plugins' ausgefuehrt. Danach werden wieder alle Scripte mit dem 'install' und dem 'config' Argument ausgefuehrt.
So gibt es also Scripte, die z.B. herunterladen und installieren, andere die patchen oder Plugins installieren, einige pruefen vorher, ob es sich z.B. um ein uClibc system handelt, sonst tun sie nix.

Die Dateistruktur ist:

root -|
|- vdr-build.sh
|- build.d
|- 010-vdr.build
|- 014-vdr-epg-patch.build
|- 016-vdr-syncearly-patch.build
|- 030-vdr-xineliboutput.build
|- 031-vdr-xineliboutput-uclibc-patch.build

Hier das 030-vdr-xineliboutput.build File:

# Sample vdr build system config file
#
# This script is executed from the main VDR build script when a component
# or plugin is to be installed into the VDR build environment.
#
# Functions within the script are:
#
#  - prep(): To configure a plugin before compiling VDR or to patch VDR
#
#  - install(): To install a plugin or feature package or its components
#
#  - config(): To write a VDR config options file for this feature or package
#
#


PACKAGE_VER="1.0.0rc2"


echo "Conf script for vdr-xineliboutput-$PACKAGE_VER"


prep() {
  echo "Starting prep for component: ${0}"

  echo "Source package."
  if [ ! -e vdr-xineliboutput-${PACKAGE_VER}.tgz ]; then
    wget http://downloads.sourceforge.net/xineliboutput/vdr-xineliboutput-${PACKAGE_VER}.tgz
    RC=$?
    if [ ! $RC == 0 ]; then
      echo FAILED;
      exit 1
    fi
  fi

  if [ X${VDR_DIR} == X ]; then
    echo "VDR directory variable not set - cannot continue !"
    exit 2
  fi

  echo "Extracting into: ${VDR_DIR}/PLUGINS/src"
  tar xzf vdr-xineliboutput-${PACKAGE_VER}.tgz -C ${VDR_DIR}/PLUGINS/src
  ln -sf ${VDR_DIR}/PLUGINS/src/xineliboutput-${PACKAGE_VER} ${VDR_DIR}/PLUGINS/src/xineliboutput


}


install() {
  echo "Starting install for component: ${0}"

  cd ${VDR_DIR}/PLUGINS/src/xineliboutput-${PACKAGE_VER}
  make install 
  cd -


}


config() {
  echo "Starting config for component: ${0}"
}


case "$1" in
  (prep)
    prep
    ;;
  (install)
    install
    ;;
  (config)
    config
    ;;
  *)
    echo $"Usage: $0 {prep|install|config}"
    exit 1
esac

Dies System ist sicherlich keine Loesung fuer alle Probleme, aber es geht zumindest auf das eine oder andere ein.
Im Augenblick arbeite ich an einem VDR startup Script, das die im Buildscript erzeugten Config-Files einliest und VDR dementsprechend Konfiguriert.

Gruss,

Giga

genau so hätt ich mir das vorgestellt...

und bevor man builded gibts dann noch ein kleines progrämmchen bzw script mit ncurses oberfläche oder wie auch immer mit der man sagt welche "packages" man gerne hätte und schwupps holt wget dann die *.build files...

das mit der anlehnung an die init-scripte find ich eine gute idee...

73

giga-san

Du gehst davon aus , daß alle externen Packages , die ein beliebiges zu buildendes Plugin benötigt vorhanden sind ?

Sonst müßte dein prep das ermitteln ...

HJS

hjs: Nein, dazu ist prep ja da - wenn ein Plugin weitere Resourcen braucht, kann es diese mit den Platform-Abhaengigen Tools bereitstellen (apt-get, yum, emerge), die Installation verweigern oder den Build mit einer entsprechenden Meldung abbrechen.

Dies sollte dann aber von einem Distro-abhaengigen Tool/Script gemacht werden.

Giga

Zitat

Original von giga-san
hjs: Nein, dazu ist prep ja da - wenn ein Plugin weitere Resourcen braucht, kann es diese mit den Platform-Abhaengigen Tools bereitstellen (apt-get, yum, emerge), die Installation verweigern oder den Build mit einer entsprechenden Meldung abbrechen.

Dies sollte dann aber von einem Distro-abhaengigen Tool/Script gemacht werden.

Die fette Variante ist mir nicht wirklich sympatisch .

Platform abhängige Tools ist n Thema für sich - das erfordert die Kenntnis des jeweiligen Package-namens , der nicht zwingend mit dem Source-namen übereinstimmt .

Die Variante komplett selbst compilieren , wenn nicht via Header oder cmd in /{,usr,opt}/{,local}/{bin,sbin,lib} ist da aus meiner Sicht die Vielversprechendste , allerdings verlieren alle Binary-based Distries dabei natürlich den Überblick in der Paketverwaltung .

HJS

naja das plugin sollte schon wissen was es alles braucht... es würde reichen ein script mit den benötigen paketen aufzurufen und das macht dann die zuordnung zu den deb,rpm,tgz-paketen... bzw den check obs nicht eh schon installiert ist...

es ist dann nur ein script immer wieder zu warten.. und wenns überhaupt nicht das richtige findet muss eben abgebrochen werden...

meine idee wäre also diese:

build script ruft plugins-install-prep-script auf

das ruft dann das check_dep-script mit dem benötigen paketnamen auf.. z.b libcap

in der check_dep gibts dann die unterscheidung nach distri und die auflösung von libcap auf den richtigen paketnamen...

damit braucht man nur an einer stelle drehn wenn ne neue distri/package-manager dazukommt weil das check_dep script ein "globales" script ist

73

Zitat

Original von olafhenkel
Hallo Gemeinde,

....

Sicher, es gibt heute viel Fertigbrei (auch nicht abfällig gemeint), der einen PC in 10 Minuten zum SAT-Rekorder macht. Es gibt einige, speziell auf VDR zugeschnittene Distris, es gibt Fertiggeräte wie den Xeatre und die Bogobox (die meiner Meinung nach aber eher mit MythTV arbeitet, wenn man sich die Screenshots da mal ansieht und von der man nicht weiss, wieso man 1 GB Speicher braucht) und da war da noch diese lustige Rollkiste, von der ebenfalls niemand weiss, wann man sie irgendwann mal in voller Funktion im Laden kaufen werden kann.

Mein Traum mittlerweile wäre es, wenn solche Grosskopfeten wie Helmut Auer (gen2vdr), Christian Siegert (Open-Source-Factory / Xeatre) und die anderen Distri-Entwickler und Plugin Cracks mit Klaus sich da irgendwie kurzschliessen würden, um die ganze Kiste für die Leute, die´s wollen, eine Sache zusammenschustern, um den VDR easy, komfortabel und in Nullkommanix via DSL über das Ethernet-Netzwerkkabel auf den neuesten Stand zu bringen.
...

Alles anzeigen

Hallo Forum,

bin neu hier und habe noch einen VHS Videorekorder unterm Fernseher (der soll aber lamgsam mal weg).
Ich könnte mir zwar so ein VDR Ssystem hochziehen habe aber keine Lust und keine Zeit... und eine vernünftige Dreambox ist mir (realtiv) zu teuer.

Der Lösungsansatz von Olaf's Problem sieht so aus:
Zertifizierte Hardware. Ein Distributor setzt die Hardware auf testet immer vernünftig danach gibt er die aktuelle Version von VDR (für seine Kunden) frei.

d.h. ich als (DAU)Kunde kaufe mir von diesem Distributor ein VDR System (Hardware) und ein Abbo für die neusten Versionen. Ich als Kunde habe damit immer ein stabiles aktuelles System.
Das System sollte nicht verändert werden können (erst nach umsetzen eines Schalters - "Garantieverlust") - das System sollte jederzeit wieder in diesen Zustand (mit "Garantie") zurückversetzt (Backup Partition?) werden können. Im offenen Zustand kann ich jetzt ein wenig basteln (Plugins) wenns schief geht setze ich as System wieder in den Zustand des Backups zurück.

Mag sich nicht jemand damit selbstständig machen ?

und dann verlangt man etwas mehr und jeder jammert das sei zu teuer ...
siehe diskussion zu wzvdr

du koenntest es ja mit einem wzvdr probieren, aber keine ahnung wie gut der tut und ob der updatefaehig ist.