RedHat: è possibile installare pacchetti in una sorta di ambiente simulato per creare RPM

Esiste uno strumento che consente di installare le dipendenze di un .spec RPM in un ambiente isolato? Non installerò tali dipendenze a livello globale sul sistema e non sono in grado di farlo poiché non ho i privilegi di root.

La ragione

Voglio creare un pacchetto A che dipende da una versione più recente di B (che non può essere installata a livello globale sul sistema).

Mi piace costruire la versione più recente di B e lasciare che il tool di creazione di installazione B 's -develin un ambiente isolato per fornire tutti i file necessari per la costruzione di A .

soluzioni

Ci sono strumenti per farlo?
In caso contrario, cosa dovrei occuparmi di quando cerco di farlo con dire chroot?
Sarebbe una cattiva pratica?

— try-catch-finally
fonte

Risposte:

Sì, lo strumento viene chiamato mocked è in EPEL.

Utilizzo tipico:

rpmbuild -bs mypackage.spec
mock -r epel-6-x86_64 mypackage-0.1-1.src.rpm

Questo è in realtà il modo preferito di creare RPM, proprio perché isola il processo dal sistema in modo che le dipendenze impreviste non vengano tirate dentro.

È possibile modificare i file in /etc/mockmodo che vengano inseriti nei propri pacchetti, repository privati, ecc. Oppure consultare i documenti per informazioni su come aggiungere mockmanualmente pacchetti all'ambiente chroot.

Si noti che gli utenti dovrebbero essere aggiunti al mockgruppo per poter utilizzare mock.

Non a caso, il kojiserver di build che Red Hat utilizza le chiamate mockper creare ogni singolo pacchetto. Se devi creare molti pacchetti in ogni momento, potrebbe valere la pena cercare un kojiserver di build.

— Michael Hampton
fonte

Grazie Michael. Sembra molto bello e sono contento che la mia domanda non sia stata così sciocca come pensavo. ;)

— try-catch-finalmente

Penso che tentare di compilare pacchetti su host di produzione sia una cattiva pratica e tentare di farlo senza i privilegi di root è più complicato che far apparire le proprie macchine di compilazione. Quello che faccio normalmente è il seguente.

Installa VirtualBox o uno strumento simile sul tuo desktop / laptop
Crea macchine virtuali 32/64 del sistema operativo che usi in produzione
Installa gli strumenti normalmente finti, rpmbuild, ecc
Crea gli RPM per il pacchetto e qualsiasi deps aggiuntivo per entrambi gli archi sulle tue VM
Dopo il test, spingere gli RPM nel repository interno per la distribuzione ai server
Testare di nuovo per assicurarsi che vengano inserite le dipendenze appropriate
Rilascio tramite la gestione della configurazione.

— Ramin
fonte

Questo funzionerà. In che modo è meglio che usare il finto? Penserei che la derisione sarebbe più facile, ma sospetto che in entrambi i casi stia succedendo praticamente le stesse cose.

— emory

Non ho alcun problema con la simulazione e credo che quasi tutti i documenti "come creare un rpm" lo abbiano installato. Tuttavia, senza accesso root non sono sicuro di come l'OP aggiungerà il proprio account al gruppo fittizio, installerà mock e così via. Anche avere VM di build pulite aiuta a evitare dipendenze dispari dall'aggiunta involontaria ai pacchetti.

— Ramin,

Punto eccellente. Non ho considerato questo. Con questo in mente, penso che questa sia la risposta corretta.

— emory

@emory in base al tuo feedback Ho chiarito il motivo per cui penso che costruire VM sia una soluzione migliore nel complesso, che penso rappresenti una risposta migliore. Grazie per avermi stimolato. :-)

— Ramin

@Ramin nella mia situazione (al lavoro) Sono solo utente . Il sistema è un sistema di build dedicato e, se tutti gli sviluppatori su quell'host avessero i privilegi di root, quella casella non si avvia dopo 1 settimana. ;) Quindi usare uno strumento come Mock è esattamente la cosa giusta da usare! Configurare le VM è anche una buona idea se può essere ben automatizzato. Penso che Vagrant (non l'ho ancora testato) è lo strumento giusto per quello.

— Try-catch-finalmente

Vuoi usare il finto. Ti permette di costruire rpms in un chroot

https://fedorahosted.org/mock/

— Mike
fonte