Il mio standard di aggiornamento automatico è ragionevole?

However, the purpose of this is not to be a package manager, but instead a standard to follow when you want to implement a system that silently, automatically updates your software in the background. I'll look through apt and rpm!

Il problema è che quello che vuoi fare è costruire un gestore di pacchetti che ti piaccia o no.

Il tuo attuale sistema proposto sembra ruotare attorno al semplice download degli installer a intervalli sconosciuti e all'esecuzione di questi. C'è molto di più che devi fare.

Questo modello dipende dal fatto che ogni pacchetto possa avere un programma di installazione silenzioso. Anche se avere un programma di installazione silenzioso è fantastico, non funzionerà con molti pacchetti software. Dovrai o ignorarli, rendendo lo 'standard' praticamente inutile, o devi definire eccezioni che possono essere canalizzate attraverso il tuo software per quando l'utente deve prendere decisioni.

Alcuni pacchetti dipendono dal framework .NET. Per Windows, ci saranno molti pacchetti. Poiché gli installer non sapranno se .NET è installato, dovranno includerlo ogni volta. Vuoi che il sistema scarichi quell'enorme ridistribuibile più e più volte? E se non lo fai, allora devi avere un modo per i software per indicare che è quello di cui hanno bisogno, in modo che il tuo sistema possa scaricarlo per loro. E avere il software iniziale non ti salverà, poiché non è raro che un determinato prodotto software cambi le versioni .net framework tra "aggiornamenti".

Molto presto, i vari pacchetti dovranno avere versioni differenti, quindi il tuo software dovrà tenere traccia di tutto ciò.

In che modo il tuo software gestirà gli aggiornamenti che non possono essere eseguiti correttamente? È inaccettabile che l'aggiornamento automatico interrompa in modo casuale un pacchetto software esistente. Dovrai implementare un sistema per gestirlo e ripristinare le modifiche. Windows Installer fornisce alcuni di questi, ma non tutti i pacchetti utilizzano Windows Installer per installarsi, e Windows Installer non è ovviamente disponibile su nessuna altra piattaforma popolare.

Non penso che ti rendi conto della complessità che questo compito richiede se risolverà problemi reali per molte persone.

L'idea di base sarebbe quella di trovare la differenza tra il set di file attualmente installati sul computer di qualcuno e il più recente insieme di file che dovrebbero essere installati sul computer specifico di quella persona; e (una volta determinate tali differenze) scaricare qualsiasi nuovo file manchi e scartare i vecchi file obsoleti; speriamo in un modo "atomico" (che rende impossibile per qualcuno avviare il software nel momento sbagliato e ottenere una miscela di vecchio e nuovo).

Si noti che determinare "deve essere installato sul computer specifico di quella persona" può implicare una certa quantità di logica. Può dipendere da quale SO l'utente ha effettivamente (Windows XP a 32 bit, Windows 8 a 64 bit?), O quale CPU hanno (con / senza AVX?), O quale versione di DirectX o Java o qualsiasi altra cosa abbiano, o se sono utenti registrati o meno (ad esempio, solo utilizzando una versione gratuita con funzionalità limitate) o se la loro scheda video può gestire trame ad alto dettaglio o no, o se hanno abilitato varie funzioni opzionali, o ...

Si noti inoltre che lo stesso sistema potrebbe (dovrebbe?) essere utilizzato per l'installazione e la disinstallazione del software. Per l'installazione del software, il set di file attualmente installati è "nulla" (quindi l'auto-aggiornamento sa che è necessario scaricare tutto nel set di nuovi file). Per disinstallare il software, puoi semplicemente far finta che il set di file più recente da installare sia "niente" e scartare il set di file attualmente installati.

Inoltre; Vorrei un po 'di sicurezza e / o tolleranza ai guasti. Ad esempio, i file possono essere crittografati con la chiave privata del provider e l'auto-aggiornamento utilizza la chiave pubblica del provider per decrittografare i file. Forse ogni file scaricato ha un checksum MD5 e (dopo la decrittografia?) L'auto-updater assicura che i dati del file corrispondano effettivamente al checksum MD5.

Parliamo della larghezza di banda. I dati sono compressi? Se c'è un file MiB 123 e la nuova versione di quel file ha solo 12 byte diversi; scarichi l'intero file 123 MiB, o scarichi solo qualcosa che descrive le differenze (" inserisci 4 byte qui, sostituisci 6 byte lì, quindi aggiungi 2 byte alla fine ")?

Che cosa memorizza il server? Memorizza solo file semplici (e comprime, cripta, ecc. Ogni volta che il file viene scaricato); o il server memorizza i file pre-compressi e pre-crittografati, oltre a memorizzare le descrizioni pre-calcolate su come convertire i vecchi file in nuovi file (quindi se stiamo aggiornando il file 123 MiB il server può fornire rapidamente " inserire 4 byte qui, sostituire 6 byte lì, quindi aggiungere 2 byte alla fine "descrizione)?

Ora; diamo un'occhiata al tuo "refine.txt". I dettagli tecnici all'interno di "refine.txt" che descrivono come funzionerà effettivamente, coprono qualcosa di importante?

Il poster originale diceva:

However, the purpose of this is not to be a package manager, but instead a standard to follow when you want to implement a system that silently, automatically updates your software in the background.

Sebbene sia possibile scrivere un aggiornamento automatico è difficile farlo correttamente senza la capacità del gestore pacchetti di controllare le dipendenze tra pacchetti.

Ad esempio, i programmi di installazione di Windows precedenti (attuali?) dipenderebbero da una determinata versione della libreria Visual C RunTime (msvcrt.dll) in modo che vengano spediti con la loro versione idiosincratica di quel file di sistema principale messo nel sistema principale directory e interrompere altre applicazioni che necessitavano di una versione diversa. L'equivalente di Unix è noto come "inferno di dipendenza" dove l'aggiornamento di X implica l'aggiornamento di Y che potrebbe richiedere il downgrade di Z. Le moderne distribuzioni si impegnano a prevenire questo inferno e usano i gestori di pacchetti per farlo.

Infine, gli auto-aggiornatori sono involucri banali attorno ai gestori di pacchetti: per ogni pacchetto installato, verifica se il server ha una versione più recente e chiedi che il gestore di pacchetti installi il nuovo. Come suggerito da @Brendan, se pensi di poter scappare con una singola "immagine di applicazione totale" monolitica per ogni macchina, rimarrai profondamente deluso dal fatto che macchine diverse avranno fastidiosamente requisiti diversi. Avrai anche il requisito del codice legacy di "Ho bisogno di mantenere groovy_app.1.1 su questa macchina perché groovy_app.2.1 interrompe la mia missione mission-critical".

Le organizzazioni resistono al cambiamento in generale. I resisti organizzativi dell'IT cambiano ancora di più perché ogni cambiamento è un salto discreto e stridente per la maggior parte delle persone coinvolte. L'aggiornamento di Google Chrome è un modello inadeguato da seguire in quanto è un sistema monolitico completo. Sì, le nuove versioni di Chrome interromperanno occasionalmente le estensioni esistenti (incluse quelle "di Google"), ma semplicemente non gli interessa. Possono farla franca perché sono GOOG, probabilmente non ci riesci.