updates von eigenen programmen, wie erstelle ich updatedateien? (Allgemeines zu Perl)

[thread]14039[/thread]

updates von eigenen programmen, wie erstelle ich updatedateien?

Leser: 28

Articles: hide open all | hide show old branches

+16 replies
#Kein Kommentar

2009-09-18 16:38

User since
2007-06-09
575 Artikel
HausmeisterIn

hallo community,

ich bin gerade dabei eines meiner projekte komplett neu zu schreiben, sprich ein altes projekt, welches ich bis jetzt stets gewartet und gepflegt habe, mit meinem neueren programmierstil und erfahrungen besser und einfacher zu schreiben.

soviel zu meinem vorhaben... jetzt habe ich aber eher eine ganz andere frage: mein programm soll eine update-funktion besitzen, d.h. der benutzer soll das programm mit einer netten und komfortablen funktion updaten können. bis jetzt kein problem.

doch wie kann ich update-dateien erstellen? ich möchte ja nicht bei jedem kleinen update den benutzer das ganze programm herunterladen lassen. auch dieses problem habe ich gelöst, indem ich das programm WinMerge benutze, damit kann man zwei dateien oder ordner miteinander vergleichen und daraus update-dateien erstellen.

wenn der benutzer allerdings mal ein update direkt verpasst und es schon das nächste update gibt... wie mache ich das dann? also sprich der benutzer hat version 1.04, es gibt allerdings schon version 1.06. wenn er jetzt updaten will, soll ich dann jedes einzelne package herunterladen und installieren? (also 1.05 und 1.06). das hätte eben einen großen traffic-verbrauch. wenn ich allerdings nur die änderung von version 1.06 installiere (und 1.05 auslasse), wird es wahrscheinlich zu programmfehlern kommen, weil dateien teilweise veraltet sind.

wie handhabt ihr das, wenn ihr programme schreibt, die ihr updaten müsst?

viele grüße,
#Kein Kommentar
Last edited: 2009-09-18 16:39:31 +0200 (CEST)
Gerade weil wir alle in einem Boot sitzen, sollten wir froh sein, dass nicht alle auf unserer Seite sind
- +2 replies
- pq
  
  2009-09-18 16:49
  
  User since
  2003-08-04
  12208 Artikel
  Admin1
  
  was schreibst du denn für grosse programme, dass man die nicht komplett runterladen will? wenn du da noch andere dateien wie icons, templates o.ä. drin hast, kannst du das ja separieren, so dass man nur das runterladen muss, was sich geändert hat. der perlcode wird ja nicht so riesig sein?
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - #Kein Kommentar
    
    2009-09-20 12:02
    
    User since
    2007-06-09
    575 Artikel
    HausmeisterIn
    
    es ist eben noch eine ganze perldistribution von strawberry perl drauf, die ich für das programm benötige. und an dieser distribution ändere ich manchmal ein paar module und scripts. d.h. rein theoretisch könnten sich ca. 34 mb perlcode ändern.
    Gerade weil wir alle in einem Boot sitzen, sollten wir froh sein, dass nicht alle auf unserer Seite sind
- +5 replies
- sid burn
  
  2009-09-18 18:11
  
  User since
  2006-03-29
  1520 Artikel
  BenutzerIn
  
  Ich würde das Programm ganz normal als ein CPAN Modul schreiben. Volkommen egal ob du dies nun später auf dem CPAN hochlädst oder nicht. Dadurch kannst du die infrastruktur nutzen die dir die Module anbieten (automatische Modulinstallation, testumgebung etc.). Eine Automatische Installation der Programme gehört ja ebenfalls dazu, inklusive manpages erzeugung etc.
  
  Ansonsten wenn es ein Open Source Projekt ist, und du es letztendlich doch im CPAN hochlädst kann jeder dein Programm mit einem simplen "cpan PROGRAMMNAME" installieren/updaten.
  
  Ansonsten würde ich immer vollständige Packete bauen wo bereits alles enthalten ist. Wenn ein Fremder das Programm herunterlädt ist somit bereits alles enthalten. und er muss nicht eine alte version + xx upgrade packete herunterladen.
  
  Natürlich kannst du auch beides immer bauen, sprich alles zusammen und upgrade packet, nur stellt sich die Frage ob sich das vom aufwand her lohnt.
  
  Um ein paar Programme zu nennen die so verfahren:
  Padre
  MojoMojo
  App::*
  Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
  - +4 replies
  - #Kein Kommentar
    
    2009-09-20 12:04
    
    User since
    2007-06-09
    575 Artikel
    HausmeisterIn
    
    das klingt interessant, gibt es eine gute anleitung wie man ein cpan-modul schreiben kann? ich habe soetwas nämlich noch nie gemacht
    Gerade weil wir alle in einem Boot sitzen, sollten wir froh sein, dass nicht alle auf unserer Seite sind
    - +2 replies
    - MatthiasW
      
      2009-09-20 12:34
      
      User since
      2008-01-27
      367 Artikel
      BenutzerIn
      
      Dazu gibt es einen guten WIKI-Artikel: Wie erstelle ich ein Modul
      
      MfG
      perl -E'*==*",s;;%ENV=~m,..$,,$&+42;e,$==f;$"++for+ab..an;@"=qw,u t,,print+chr;sub f{split}say"@{=} me"'
      - pq
        
        2009-09-20 14:39
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        hui, der artikel ist auch schon reichlich veraltet.
        das hier ist aktueller: http://p3rl.org/perlnewmod
        da wird dann auch module-starter erwähnt.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
    - sid burn
      
      2009-09-20 18:51
      
      User since
      2006-03-29
      1520 Artikel
      BenutzerIn
      
      Du kannst dir mal Module::Starter anschauen. Das legt dir bereits die Infrastruktur an für ein Modul.
      
      Danach kannst du deine Module unter dem Verzeichniss "lib" ablegen. Selber als Hilfe nutzt du dann wahlweise ExtUtils::MakeMaker, Module::Build oder Module::Install.
      
      Ich würde da persönlich Module::Build empfehlen.
      
      ExtUtils::MakeMaker (EUMM) ist das erste Buildsystem was es gab und shcon etwas veraltet/kompliziert. Weiterhin benötigt du noch externe Module wie "make" damit es Funktioniert. Bei diesem bearbeitest du dann hauptsächlich auch eine "Makefile.PL" für dein Modul.
      
      Module::Build (MB) und Module::Install (MI) sind beides Pure Perl Module. Daher du brauchst nur ein installiertes Perl damit diese Funktionieren. Das ist Platformkompatibler als EUMM und macht auf Windows z.B. keine Probleme.
      
      Ansonsten kenne ich beides da Catalyst immer MI Standardmäßig nutzt, und bisher habe ich selber immer MB genutzt. Würde dir aber MB nahelegen da ich finde das es einfacher zu bedienen und teilweise auch mehr Funktionalitäten hat. MB legt dir auch gleich so eine reihe von Helfer Dateien an z.B. Ignore Files die du super nutzen kannst für Versionierungssysteme. Auch so beachtet MB einige sachen. Mehr, veränderst du z.B. Dateien in "lib" und rufst "./Build test" auf dann erkennt er z.B. das du die Dateien verändert hast und ruft implizit für dich "./Build" auf. Wenn du bei MI z.B. "make test" aufrufst dann laufen deine Tests gegen die Module seit dem du das letzte mal "make" aufgerufen hast. Es ist mir schon ein haufen mal passiert das tests fehlgeschlagen sind, ich die ganze Zeit im "lib" verzeichniss geschaut habe warum diese noch fehlschlagen und mir dann später eingefallen ist: "Ahh stimmt ich muss ja vorher noch "make" ausführen". Das ist nur so ein Beispiel auch hat MB einige Optionen mehr die du mit "./Build help" erfährst.
      
      Module::Install ist zwar ebenfalls Pure Perl, versucht aber möglichst Kompatibel zu EUMM zu sein. Daher du hast wieder eine Makefile.PL die du bearbeites, bei MB bearbeitest du eine Build.PL. Alelrdiengs benötigst du wieder "make" um deine Module zu installieren, was bei MB komplett weg fällt. Zur Kompatibilität sei aber gesagt das MB ebenfalls immer eine Makefile.PL erstellt aus deiner Build.PL Datei heraus. Daher jemand kann ebenfalls noch seine Module über "make" installieren.
      
      Ich hatte erst letztens noch einen Beitrag geschrieben wo ich anhand von Module::Starter und Module::Build das aufsetzen eines Moduls erklärt habe. Zumindest sind das die Absoluten Grundlagen. http://www.perl-community.de/bat/poard/message/125...
      Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
- +8 replies
- moritz
  
  2009-09-21 11:14
  
  User since
  2007-05-11
  923 Artikel
  HausmeisterIn
  
  Ich war bisher nicht in der Verlegenheit, so etwas zu machen, aber ich wuerde schlicht und ergreifend ein Versionskontrollsystem nehmen und da die releases reinschmeissen. Git z.B. bietet eine sehr gute Delta-Kompression, damit sind die updates, die man sich herunterladen muss, recht klein.
  
  Der updater kann einfach 'git pull' ausfuehren, und git kuemmert sich um das dowloaden und das automatische Anwenden der Patches. Und kryptographische Checksummen hast du auch gleich mitgeliefert...
  Perl 6 - Perls Zukunft
  - +7 replies
  - sid burn
    
    2009-09-21 11:28
    
    User since
    2006-03-29
    1520 Artikel
    BenutzerIn
    
    Quote
    Ich war bisher nicht in der Verlegenheit, so etwas zu machen, aber ich wuerde schlicht und ergreifend ein Versionskontrollsystem nehmen und da die releases reinschmeissen.
    
    Ein Versionierungssystem sollte man letztendlich sowieso nehmen und darüber auch die Releases und versionen pflegen, allerdiengs finde ich nicht das es für einen "Endkunden" akzeptabel ist Git zu nutzen und darüber seine programme zu updaten. Sowas ist dann meiner Ansicht nach doch eher für Entwickler gedacht.
    
    Vor allem möchte man Endkunden nicht immer Entwickler Versionen anbieten sondern Stable releases. Dann muss man praktisch noch jemanden Git erklären damit dieser in der lage ist zwischen versionen hin und her zu wechseln.
    
    Und hoffentlich gibt es keine konflikte, oder ähnliches...
    
    Quote
    Git z.B. bietet eine sehr gute Delta-Kompression, damit sind die updates, die man sich herunterladen muss, recht klein.
    
    Wenn man es genau nimmt. Git speichert immer die vollständige Datei bei jedem commit, und die vollständigen Dateien werden auch immer vollständig heruntergeladen/synchronisiert. Deltas speichert Git intern nicht.
    
    Ansonsten weil Git immer die vollständige History enthält muss jeder immer das vollständige Projekt herunterladen mit allen Versionen/Revisionen jeder Datei seit start des Projektes.
    Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
    - +6 replies
    - moritz
      
      2009-09-21 12:47
      
      User since
      2007-05-11
      923 Artikel
      HausmeisterIn
      
      2009-09-21T09:28:17 sid burn
      Quote
      Ich war bisher nicht in der Verlegenheit, so etwas zu machen, aber ich wuerde schlicht und ergreifend ein Versionskontrollsystem nehmen und da die releases reinschmeissen.
      
      Ein Versionierungssystem sollte man letztendlich sowieso nehmen und darüber auch die Releases und versionen pflegen, allerdiengs finde ich nicht das es für einen "Endkunden" akzeptabel ist Git zu nutzen und darüber seine programme zu updaten. Sowas ist dann meiner Ansicht nach doch eher für Entwickler gedacht.
      
      Wieso ist es nicht akzeptable, wenn das Programm sich selbst ueber Git updated? Der Anwender muss davon nichts mitbekommen.
      
      Quote
      Vor allem möchte man Endkunden nicht immer Entwickler Versionen anbieten sondern Stable releases.
      
      Deswegen habe ich auch geschrieben, man soll die Releases ins git-repo reinkippen - ich habe nie behauptet, man soll fuer Entwicklung und Verteilung das gleiche Repo benutzen.
      
      Quote
      Dann muss man praktisch noch jemanden Git erklären damit dieser in der lage ist zwischen versionen hin und her zu wechseln.
      
      Muss man nicht. Siehe oben.
      
      Quote
      Und hoffentlich gibt es keine konflikte, oder ähnliches...
      
      Wo sollen Konflikte herkommen, wenn Updates immer nur vom selben Repo bezogen werden?
      
      Quote
      Quote
      Git z.B. bietet eine sehr gute Delta-Kompression, damit sind die updates, die man sich herunterladen muss, recht klein.
      
      Wenn man es genau nimmt. Git speichert immer die vollständige Datei bei jedem commit, und die vollständigen Dateien werden auch immer vollständig heruntergeladen/synchronisiert. Deltas speichert Git intern nicht.
      
      Ansonsten weil Git immer die vollständige History enthält muss jeder immer das vollständige Projekt herunterladen mit allen Versionen/Revisionen jeder Datei seit start des Projektes.
      
      Stimmt nicht. Git unterstuetzt "shallow clones", siehe z.B. die --depth-Option in der git-clone manpage.
      Perl 6 - Perls Zukunft
      - +5 replies
      - sid burn
        
        2009-09-21 15:01
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        Quote
        Wieso ist es nicht akzeptable, wenn das Programm sich selbst ueber Git updated? Der Anwender muss davon nichts mitbekommen.
        
        Und wie willst du das machen? Git gleich in deine Anwendung einbauen so das der Anwender auch immer ein Git installiert hat? Oder Git vorraussetzen bei der Installation nur damit er Updaten kann? Ich finde diese Lösung viel zu kompliziert und komplett an der Aufgabenstellung vorbei.
        
        Ich finde Git zwar ein super VCS, aber es in die Anwendung zu integrieren nur zum updaten ist meiner ansicht nach zu kompliziert oder eine unnötige viel zu große Abhängigkeit.
        
        Quote
        Deswegen habe ich auch geschrieben, man soll die Releases ins git-repo reinkippen - ich habe nie behauptet, man soll fuer Entwicklung und Verteilung das gleiche Repo benutzen.
        
        Wenn man natürlich ein extra Repository pflegt wo immer nur die Stable Versionen vorhanden sind ist es noch halbwegs machbar, okay das stimmt.
        
        Quote
        Stimmt nicht. Git unterstuetzt "shallow clones", siehe z.B. die --depth-Option in der git-clone manpage.
        
        Das ist korrekt für den bezug das man nicht immer die komplette History benötigt (wuste auch nicht das es das kann, wurde im Buch auch gar nicht erwähnt), aber Git tauscht trotzdem keine Deltas aus.
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
        
        +4 replies
        
        moritz
        
        2009-09-21 15:43
        
        User since
        2007-05-11
        923 Artikel
        HausmeisterIn
        
        [quote="sid burn@2009-09-21T13:01:28"]
        Quote
        Quote
        Stimmt nicht. Git unterstuetzt "shallow clones", siehe z.B. die --depth-Option in der git-clone manpage.
        
        Das ist korrekt für den bezug das man nicht immer die komplette History benötigt (wuste auch nicht das es das kann, wurde im Buch auch gar nicht erwähnt), aber Git tauscht trotzdem keine Deltas aus.
        
        Keine Deltas? Hast du einen Beleg fuer diese Aussage?
        
        Ein "git clone" dauert wesentlich Laenger als als "git pull", was sich nur Aenderungen reinholt - fuer mich ist das ein klares Zeichen davon, dass tatsaehlich Deltas ausgetauscht werden, und nicht immer das komplette Repository uebertragen wird.
        Perl 6 - Perls Zukunft
        
        +3 replies
        
        sid burn
        
        2009-09-21 15:57
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        Quote
        Keine Deltas? Hast du einen Beleg fuer diese Aussage?
        
        Ich habe das Buch http://www.amazon.de/Version-Control-Git-Jon-Loeli... gelesen. Da wird ausführlich erklärt wie Git intern arbeitet. Intern arbeitet Git so das es jede Datei vollständig Speichert und darüber eine SHA1 Summe generiert. Dieses ist dann für Git ein "objekt".
        
        Änderst du eine Datei wird die neue Datei wieder komplett gespeichert und die SHA1 Summe gespeichert und du hast ein weiteres neues Objekt. Deltas werden bei git nur dann generiert wenn es nötig ist. z.B. bei einem "git diff" aber werden letztendlich nie gespeichert.
        
        Hast du also drei unterschiedliche versionen einer Datei, ist die Datei dreimal vollständig im Repro enthalten. SVN als Beispiel speichert nur die Deltas. Also bei einer neuen commit werden nur die Deltas gespeichert um von der vorherigen version zur nächsten zu kommen, also ein Patch, aber nicht mehr die vollständige Datei.
        
        Andere "öffentlichen Quellen" kann ich gerade dafür nicht nennen.
        
        Quote
        Ein "git clone" dauert wesentlich Laenger als als "git pull", was sich nur Aenderungen reinholt - fuer mich ist das ein klares Zeichen davon, dass tatsaehlich Deltas ausgetauscht werden, und nicht immer das komplette Repository uebertragen wird.
        
        Hmm, was verstehst du nun unter Deltas? Ich verstehe darunter z.B. das was "git diff" liefert, also nur die unterschiede zweischen zwei dateien.
        
        Bei einem "git pull" werden latztendlich natürlich nur die fehlende objekte geholt die in deinem Repository noch nicht vorhanden sind. Wenn du das unter Delta verstanden hast, dann ja das macht Git natürlich auch.
        
        Trotzdem werden keine Deltas von Dateien ausgetauscht, sondern jedesmal die kompletten Objekte und somit die kompletten Dateien komplett synchronisiert. Ein "git pull" ist also natürlich auch schneller, weil du nicht mehr alle Objekte übertragen musst wie bei einem "git clone".
        Last edited: 2009-09-21 16:01:17 +0200 (CEST)
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de
        
        +2 replies
        
        moritz
        
        2009-09-21 19:02
        
        User since
        2007-05-11
        923 Artikel
        HausmeisterIn
        
        Also ich meine sowas wie hier aus dem Git-Wiki:
        
        Quote
        [...] so objects can be combined into packs, which use delta compression to save space, storing blobs as their changes relative to other blobs.
        
        Und meiner Erfahrung nach ist es dabei verdammt effizient.
        Perl 6 - Perls Zukunft
        
        sid burn
        
        2009-09-21 19:20
        
        User since
        2006-03-29
        1520 Artikel
        BenutzerIn
        
        Quote
        Also ich meine sowas wie hier aus dem Git-Wiki:
        
        Führt leider zu einer nicht existenten seite?
        
        Quote
        [...] so objects can be combined into packs, which use delta compression to save space, storing blobs as their changes relative to other blobs.
        
        Hmm, wie die Komprimierung letztendlich genau arbeitet weiß ich nicht. Das Buch behandelt die etwas höhere ebene wie Git Dateien ansieht. Aber die Aussage die dort steht entspricht trotzdem genau dem entgegen was im Buch steht.
        
        Weiterhin sind einige Features und die geschwindigkeit von Git gerade nur deswegen möcglich weil es eben keine Deltas speichert. Und das ist auch der Hauptgrund warum Git kein "verschieben von Dateien" versteht (zumindest technisch).
        
        Und im letzten Kapitel zu "git svn" wird das sogar als ein hauptunterschied zu SVN zu Git erwähnt.
        
        Könnte aber durchaus sein das Git auf der höheren ebene die vollständigen Dateien Speichert, aber intern die Kompression das eben wieder heraus nimmt. Dafür ist ja auch eine Kompression dar.
        Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

View all threads created 2009-09-18 16:38.