2009-04-06 11 views
21

Ho diverse applicazioni che desidero distribuire usando rpm. Alcuni dei file nelle distribuzioni dell'applicazione sovrascrivono i file di altri pacchetti distribuiti. Includere semplicemente i nuovi file nel pacchetto di distribuzione causerà conflitti di rpm.Come utilizzare rpm per aggiornare/sostituire i file esistenti?

Sto cercando il modo corretto di utilizzare rpm per aggiornare/sostituire i file già installati.

Ho già trovato alcune soluzioni, ma nulla sembra giusto.

  • Mantenere versioni personalizzate degli rpms contenenti i file originali.

Questa sembra una grande quantità di lavoro per una ricompensa relativamente piccola, anche se sembra meno un compromesso rispetto ad alcune delle altre possibili soluzioni.

  • Includi i file in rpm con un altro nome e copiali nella sezione dei post.

Ciò funzionerebbe ma significherebbe sporcare il sistema con più copie dei file. Significa anche una manutenzione aggiuntiva nella specifica di build rpm per ogni file.

  • Utilizzare wget nella sezione post per sostituire i file originali da un server noto.

Questo è simile alla tecnica di copia, ma i file non potrebbero nemmeno vivere in rpm. Tuttavia, ciò potrebbe comportare una buona autorità di configurazione centrale.

  • Distribuire i file come nuovi file, quindi utilizzare i collegamenti simbolici per sovrascrivere gli originali.

Questo è anche simile alla tecnica di copia ma con meno ingombro. Il problema qui è che alcuni file non si comportano bene come collegamenti simbolici.

risposta

11

Al meglio della mia conoscenza, RPM non è progettato per consentire l'aggiornamento/sostituzione file esistenti, quindi tutto ciò che si fa sta per essere un hack.

Delle opzioni elencate, sceglierei il # 1 come la meno cattiva hack se i sistemi di destinazione sono sistemi che io amministro (come dici tu, è più lavoro ma è la soluzione più pulita) e una combinazione di # 2 e # 4 (dove possibile, copie dove no) se sto creando gli RPM per i sistemi degli altri (per evitare di dover distribuire un gruppo di RPM, ma lo renderei molto chiaro nei documenti cosa sono sto facendo).

Non è stato descritto quali file devono essere aggiornati o sostituiti e come devono essere aggiornati. A seconda delle risposte a queste domande, si può avere un paio di altre opzioni:

  • Molti programmi sono progettati per utilizzare un singolo file di configurazione di default e anche per afferrare i file di configurazione da un .d sottodirectory.Ad esempio, Apache utilizza /etc/httpd/conf/httpd.conf e /etc/httpd/conf.d/*.conf, pertanto i tuoi RPM potrebbero rilasciare file sotto /etc/httpd/conf.d invece di modificare /etc/httpd/conf/httpd.conf. E se i file che devi modificare sono file di configurazione che non seguono questo modello ma potrebbero essere creati, puoi suggerire ai manutentori del pacchetto di aggiungere questa funzionalità; questo non ti aiuterebbe immediatamente ma renderebbe le prossime uscite più facili.
  • Per utilità della riga comandi come sendmail e lpr che possono essere forniti da più pacchetti, il sistema alternatives (vedi man alternatives) permette più di 1 RPM che fornisce queste utilità per essere montati affiancati. Anche in questo caso, se i file che è necessario modificare sono utilità della riga di comando che non seguono questo modello ma potrebbero essere apportate, è possibile suggerire ai manutentori del pacchetto di aggiungere questa funzionalità.
  • Le modifiche ai file di configurazione sui sistemi amministrati vengono gestite meglio tramite uno strumento come Cfengine o Puppet anziché tramite RPM personalizzati. Penso che Red Hat favorisca Puppet.
  • Se stavo creando gli RPM per i sistemi che non amministro, prenderei in considerazione l'utilizzo di uno strumento di terze parti come Bitrock e il dumping di tutte le mie cose sotto /opt solo così non avrei bisogno di calpestare i file installati da RPM degli altri amministratori.
0

Hai controllato la documentazione di rpm e la mailing list? Ecco uno su rpmsave e rpmnew che copre il problema: http://www.redhat.com/archives/fedora-list/2003-December/msg04713.html

+0

Questo è un buon suggerimento, ma la funzione rpmnew/rpmsave si riferisce in realtà all'aggiornamento di un pacchetto esistente. Il problema che sto avendo riguarda l'aggiunta di un nuovo pacchetto che modifica i file già installati da un altro pacchetto. Grazie! – tremoloqui

+0

L'aggiornamento dei file di un altro pacchetto non mi sembra molto sicuro. Perché dovresti avere problemi con i file di altri pacchetti, in primo luogo? – lothar

+0

Esempio di esempio: il pacchetto perl-5.8.8 su CentOS contiene molte versioni precedenti di moduli CPAN, che non sarà possibile aggiornare tramite RPM perché i file del modulo aggiornati saranno in conflitto. Quindi sei bloccato con i vecchi moduli o ti ci fai strada. –

2

Vedi qui per maggiori informazioni su RPM% direttive file:

http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html

È possibile utilizzare gli argomenti dal post% e% sezioni pre negli scriptlet RPM per determinare se si sta installando, aggiornamento o rimozione dei pacchetti.

Se $ 1 è 0, allora rimuoviamo le vecchie cose. Targeting di 0 pacchetti installati. Se $ 1 è 1, allora stiamo installando nuove cose. Targeting per un totale di 1 pacchetto da installare. Se $ 1 è 2 o più - allora stiamo aggiornando questo pacchetto e $ 1 rappresenta il numero di pacchetti già installati.

Queste sezioni aiutano nella gestione dei file tra le versioni. Tieni traccia di ciò che stai facendo tra una versione e l'altra e considera cosa si potrebbe fare se dovessero saltare una versione o due.

Prendi in considerazione queste cose e dovresti essere pronto!

2

È inoltre possibile eseguire rpm -U --replacefiles --replacepkgs ..., che consente di ottenere ciò che si desidera.

+0

Um non proprio. Mentre l'installazione sostituirà i file, l'operazione non è persistente. Il prossimo aggiornamento annullerà --replacefiles. Si noti che --replacepkgs è in gran parte irrilevante a meno che il pacchetto abbia lo stesso nome. –

+1

Inoltre non ci si può aspettare che funzioni quando gli utenti estraggono il pacchetto da un server yum. – Jolta

Problemi correlati