openSUSE:Build Service Tutorial

Open Build Service

Τελικός χρήστης - Πακετάς - Ανάπτυξη - Ενσωμάτωση KIWI - Εγκαταστάσεις - Συνεργασία - Σύγκριση

Οδηγίες Πακεταρίσματος

Αυτό το έγγραφο δίνει μια επισκόπηση του Build Service και αποτελεί έναν οδηγό για το πώς να κατασκευάσετε πακέτα για διαφορετικές διανομές χρησιμοποιώντας το καταπληκτικό αυτό εργαλείο. Θα προσπαθήσουμε να δείξουμε όλες τις ενέργειες με ένα παράδειγμα εφαρμογής ώστε να μπορέσετε να ακολουθήσετε τα βήματα για να παράγετε τα δικά σας πακέτα

Περιεχόμενα

1 Προαπαιτούμενα
2 Απαιτήσεις
3 Ορολογία
4 Ροή Εργασιών
5 Ένα ολοκληρωμένο παράδειγμα μιας απλής αλλαγής
6 Δείτε επίσης

Προαπαιτούμενα

Πρέπει να έχετε μια γενικότερη κατανόηση γύρω από τα RPM και το πώς κατασκευάζονται. Δείτε τις κατευθυντήριες γραμμές πακεταρίσματος για το openSUSE ή κάποιο παρόμοιο έγγραφο για άλλα υποστηριζόμενα συστήματα όπως το dpkg. Αυτό το έγγραφο δεν σκοπεύει να αντικαταστήσει την τεκμηρίωση πακεταρίσματος, που βρίσκεται στους παραπάνω συνδέσμους.

Πρέπει επίσης, να είστε εξοικειωμένοι με το περιβάλλον πηγαίου κώδικα που χρησιμοποιεί το έργο για το πακέτο σας. Το Build Service μπορεί να ξεπεράσει κάποια συνηθισμένα λάθη και θα προσπαθήσει να σας καθοδηγήσει σε περιπτώσεις αποτυχιών. Έχουμε μια λίστα ηλεκτρονικού ταχυδρομείου για το buildservice που μπορεί να παρέχει βοήθεια και συμβουλές. Ωστόσο, αποφάσεις σχετικά με το ποιες διορθώσεις (patch) θα εφαρμόσετε, ποιες ρυθμίσεις (flag) μεταγλωττιστή θα χρησιμοποιήσετε, κλπ είναι αποκλειστικά δικές σας.

Απαιτήσεις

Για μπορέσετε να χρησιμοποιήσετε πλήρως το Build Service πρέπει να κάνετε login με τον openSUSE/SUSE λογαριασμό σας (όπως στα wiki, bugzilla...). Αν δεν έχετε ακόμα λογαριασμό, κάνετε κλικ στο σύνδεσμο "sign up" στην κορυφή της σελίδας για να δημιουργήσετε κάποιον. Έχετε υπόψιν ότι αν αλλάξετε τον κωδικό σας κάποια φορά θα χρειαστεί να αλλάξετε και το ~/.oscrc, γιατί αν δεν το κάνετε και εκτελέσετε εντολές με το osc που έχει ούτως ή άλλως επικοινωνία με τον εξυπηρετητή, ο λογαριασμός χρήστη μπορεί να κλειδωθεί ύστερα από τις επαναλαμβανόμενες αποτυχημένες προσπάθειες με λάθος κωδικό.

Επιπλέον, αν ξεκινάτε την κατασκευή ως απλός χρήστης (καλή ιδέα!), θα σας ζητηθεί ο κωδικός του διαχειριστή root του τοπικού σας μηχανήματος. Μπορείτε να το αποφύγετε αυτό αν προσθέσετε το χρήστη σας στο /etc/sudoers με την ακόλουθη διαδικασία:

Ανοίξτε το αρχείο ρυθμίσεων ~/.oscrc.
Προσθέστε την ακόλουθη γραμμή και αποθηκεύστε το:
```
su-wrapper = sudo
```
Εκτελέστε την ακόλουθη εντολή:
```
sudo /usr/sbin/visudo
```
Προσθέστε την ακόλουθη γραμμή και αντικαταστήστε το LOGIN με το όνομα εισόδου σας:
```
LOGIN    ALL = NOPASSWD: /usr/bin/build
LOGIN    ALL = NOPASSWD: /usr/bin/osc
```

Ορολογία

Το Build Service περιλαμβάνει έργα (projects) (μπορείτε να δείτε μια λίστα εδώ). Κάθε έργο περιέχει τις απαραίτητες πηγές για την κατασκευή ενός ή περισσότερων πακέτων (packages) (πχ, RPM/DEB/κλπ.). Αυτές οι πηγές περιλαμβάνουν πηγαία αρχεία, αρχεία διορθώσεων (patch), αρχεία spec, κλπ. Το προϊόν ενός έργου είναι ένα ή περισσότερα αποθετήρια (repositories). Ένα αποθετήριο είναι η παλιά καλή γνωστή ιστορία: απλά ένας σωρός από RPM οργανωμένα σε μια ιεραρχία φακέλων μαζί με κάποια αρχεία ευρετηρίου/μετα-δεδομένων που διευκολύνουν εργαλεία όπως το zypper να κάνουν αναζήτηση και να επιλύουν εξαρτήσεις. Τα αποθετήρια που προκύπτουν από κάποιο έργο αντιστοιχούν σε διαφορετικές εκδόσεις λειτουργικών συστημάτων όπως openSUSE 11.2, κλπ.

Όσον αφορά τα υπάρχοντα έργα, υπάρχουν "επίσημα" έργα openSUSE που κατασκευάζουν RPM για τις κανονικές openSUSE διανομές. Το έργο "factory" είναι το υπό-κατασκευή έργο που θα γίνει η επόμενη έκδοση του openSUSE. Υπάρχουν επίσης πολλά έργα συγκεκριμένα με κάποιο τομέα όπως το Apache και το network:telephony. Τέλος, ο κάθε χρήστης έχει το δικό του έργο για να μπορεί να "παίζει", το οποίο ονομάζεται home:username.

Τα RPM τείνουν να έχουν πολλές εξαρτήσεις σε άλλα RPM, και συχνά αυτά τα RPM προέρχονται από διαφορετικά έργα εντός του Build Service. Αυτό έχει δυο σημαντικές επιπτώσεις.

Πρώτον, αν το πακέτο σας εξαρτάται από κάποιο άλλο κατά την εκτέλεση ("Requires"), πιθανότατα να εξαρτάται και κατά την κατασκευή του (πχ, "BuildRequires"). Το Build Service δεν ψάχνει αυτόματα τις εξαρτήσεις για την κατασκευή (εκτός από ότι συμπεριλαμβάνεται εξ ορισμού στη διανομή για την οποία κατασκευάζετε). Συνεπώς, κάπως πρέπει να του ορίσετε που θα βρει το απαιτούμενο πακέτο.

Δεύτερον, καλό είναι ένα αποθετήριο να είναι μεταβατικά κλειστό, πχ. οποιαδήποτε εξάρτηση των πακέτων του αποθετηρίου ικανοποιείται από το ίδιο το αποθετήριο (εκτός των πακέτων που υπάρχουν στην ίδια τη διανομή). Κατ' αυτόν τον τρόπο διευκολύνονται οι χρήστες που εγκαθιστούν τα RPM που παρέχει το έργο σας. Ωστόσο δεν είναι απαραίτητο κάτι τέτοιο: οι χρήστες μπορούν πάντα να βρουν αυτές τις εξαρτήσεις χρησιμοποιώντας την υπηρεσία αναζήτησης.

Το Build Service παρέχει διάφορους τρόπους για να διευκολύνει το χειρισμό αυτών των εξαρτήσεων.

Πρώτον, μπορείτε απευθείας να προσθέσετε το(α) απαιτούμενο(α) πακέτο(α) στο αποθετήριό σας. Αυτή είναι και η καταλληλότερη προσέγγιση σε περίπτωση που κανένα άλλο έργο δεν κατασκευάζει τα απαιτούμενα πακέτα. Ένα τυπικό σενάριο βέβαια είναι αυτά τα πακέτα να υπάρχουν ήδη από κάποιο άλλο έργο, οπότε λάβετε υπόψη την αξιοποίηση της υπάρχουσας δουλειάς.

Η δεύτερη επιλογή είναι να συνδέσετε το αποθετήριο του άλλου έργου με το δικό σας. Αυτό ονομάζεται διαστρωμάτωση (layering) και γίνεται αλλάζοντας τα μετα-δεδομένα του έργου σας. Απλά προσθέτετε το άλλο έργο/αποθετήριο ως μια επιπλέον διαδρομή. Με αυτόν τον τρόπο το Build Service θα ψάξει για εξαρτήσεις τύπου "BuildRequires" κατά την κατασκευή και σε άλλα αποθετήρια, επιτρέποντας την επιτυχή κατασκευή του πακέτου σας, αλλά χωρίς να πλησιάζει το στόχο του "μεταβατικά κλειστού": οι χρήστες θα πρέπει να πάνε και να φέρουν τα απαιτούμενα πακέτα από μόνοι τους. Ωστόσο, αυτό αποτελεί μια καλή λύση όταν το έργο σας έχει πολλές εξαρτήσεις από κάποιο άλλο και οι χρήστες πιθανότατα να χρησιμοποιήσουν και τα δυο αποθετήρια ούτως ή άλλως.

Η τρίτη επιλογή ονομάζεται σύνδεση (linking) και είναι ένας τρόπος να επιτρέψετε στο έργο σας να ξαναχρησιμοποιήσει ένα πακέτο που ήδη υπάρχει σε άλλο έργο. Όταν συνδέετε ένα πακέτο στο έργο σας, πακέτα που εξαρτώνται από αυτό θα μπορούν να κατασκευαστούν, και το πακέτο θα εμφανίζεται και στο αποθετήριο του έργου σας, λύνοντας και τα δύο ζητήματα χωρίς να γίνεται διπλή δουλειά.

Υπάρχουν δυο τύποι σύνδεσης: απλή και συνολική. Στην απλή, μπορείτε προαιρετικά να αλλάξετε τον τρόπο κατασκευής του συνδεόμενου πακέτου. Μπορείτε να προσθέσετε διορθώσεις, και να ενεργοποιήσετε την κατασκευή και για επιπλέον αποθετήρια. Το RPM που κατασκευάζετε θα έχει ένα διαφορετικό αριθμό κατασκευής από το αρχικό. Προσοχή, αυτό μπορεί να προκαλέσει σύγχυση στους χρήστες. Στην πράξη, κατασκευάζετε μια διαφορετική έκδοση ενός πακέτου με το ίδιο όνομα.

Εκτός κι αν χρειάζεται να τροποποιήσετε το απαιτούμενο πακέτο, αντί για απλή θα πρέπει να χρησιμοποιήσετε συνολική σύνδεση. Όταν κάνετε συνολική σύνδεση, δημιουργείτε μια σύνδεση "μόνο για ανάγνωση". Το πακέτο δεν κατασκευάζεται στο δικό σας έργο: αντί αυτού, το ήδη κατασκευασμένο πακέτο αντιγράφεται στο έργο σας από το αρχικό έργο. Έτσι το ίδιο RPM (με τον ίδιο αριθμό κατασκευής) θα εμφανίζεται και στα δυο έργα. Για το χρήστη, υπάρχει λιγότερη σύγχυση αφού τα RPM είναι σαν δυο σταγόνες νερό.

Το Build Service αυτόματα ανακαλύπτει αλλαγές στα συνδεόμενα πακέτα και κάνει ανακατασκευή όλων των πακέτων που εξαρτώνται από αυτά.

Ροή Εργασιών

Τα ακόλουθα βήματα διαγραμμίζουν μια φυσιολογική ροή για τη δημιουργία ενός έργου και την προσθήκη πακέτων σε αυτό. Βέβαια σε ένα πραγματικό παράδειγμα πιθανόν να αποτύχετε σε κάποια βήματα και επομένως θα πρέπει να τα επαναλάβετε μέχρι να τα καταφέρετε. Αυτή η διαδικασία που θα περιγράψουμε εδώ είναι μόνο για να σας δώσει μια αίσθηση του τι προσπαθούμε να επιτύχουμε.

Θα σας δείξουμε δύο διαφορετικούς τρόπους όπου είναι αυτό δυνατό:

τον τρόπο μέσω της Διεπαφής ιστού
τον τρόπος μέσω της Γραμμής εντολών
Μια εναλλακτική μέθοδος είναι μέσω του MonoOSC, για την οποία ένας οδηγός υπάρχει ήδη εδώ, επομένως δε χρειάζεται να διπλοαναφερθεί.

Βήμα Ένα – Είσοδος και αρχική ρύθμιση Τοπικού Έργου

Αν έχετε ήδη ένα λογαριασμό openSUSE, τότε μιλάμε για το ευκολότερο βήμα.

Διεπαφή ιστού: Μπείτε στη σελίδα http://build.opensuse.org/ και χρησιμοποιήστε το σύνδεσμο login πάνω δεξιά για να μπείτε στο σύστημα. Μετά από αυτό το προσωπικό σας έργο είναι διαθέσιμο κάνοντας κλικ στο όνομα χρήστη σας.

Γραμμή εντολών:

Πρώτα, πρέπει να εγκαταστήσετε τον πελάτη γραμμής εντολών στο μηχάνημά σας. Μπορείτε να βρείτε πακέτα του osc για διάφορες διανομές στο αποθετήριο μεταφόρτωσης λογισμικού openSUSE-Tools (ναι: είναι κι αυτό ένα έργο στο Build Service). Χρησιμοποιήστε τον αγαπημένο σας διαχειριστή πακέτων για να εγκαταστήσετε το πακέτο για το osc.

Στη συνέχεια κάνετε "cd" στον κατάλογο που θέλετε να χρησιμοποιήσετε για τα αρχεία του έργου σας. Εδώ οι εξοικειωμένοι με το SVN θα νιώσουν "σαν στο σπίτι τους": δοκιμάστε να κάνετε checkout το έργο σας χρησιμοποιώντας τα

 cd <κατάλογος_που_περιέχει_τη_ρίζα_του_έργου>
 osc checkout home:<username>
 cd home:<username>

(αντικαταστήστε το <username> με το δικό σας όνομα χρήστη). Θα σας ζητηθεί το όνομα χρήστη σας και το συνθηματικό πρόσβασης – αμέσως μετά το osc θα προσπαθήσει να κάνει checkout πακέτα στο προσωπικό σας έργο και να δημιουργήσει ένα νέο κατάλογο που ονομάζεται home:<username>. Μπορείτε να αλλάξετε τις ρυθμίσεις σας στο αρχείο ~/.oscrc.

Βήμα Δύο – Δημιουργήστε & Ανεβάστε πακέτα

Μπορείτε να χρησιμοποιήσετε το προσωπικό χώρο ως "παιδική χαρά" για να δοκιμάσετε πακέτα τα οποία θα μεταφερθούν σε άλλα, πιο γνωστά έργα αν όλα είναι εντάξει.

Διεπαφή ιστού: Κλικ στο όνομα χρήστη σας για να ανοίξει το προσωπικό σας έργο, έπειτα κλικ στο "create new package" στην καρτέλα με τα πακέτα. Θα πρέπει να συμπληρώσετε τα επόμενα τρία πεδία κειμένου: "Όνομα" (υποχρεωτικό), "Τίτλο" και "Περιγραφή". Απλά χρησιμοποιήστε το όνομα του πακέτου για το πεδίο "Όνομα", την περίληψη του πακέτου ως "Τίτλο" και την περιγραφή για το πακέτο ως "Περιγραφή".

Μετά τη δημιουργία του πακέτου, πηγαίνετε στην καρτέλα "Sources" για να προσθέσετε αρχεία για το πακέτο σας. Πρέπει να ανεβάσετε τον πηγαίο κώδικα του πακέτου σας και τουλάχιστον ένα αρχείο spec (δείτε επίσης το openSUSE:Packaging_guidelines).

Γραμμή εντολών:

osc meta pkg -e home:<username> <packagename>

Το osc θα ανοίξει ένα πρότυπο αρχείο xml στον αγαπημένο κειμενογράφο σας (σύμφωνα με τη μεταβλητή περιβάλλοντος EDITOR) και μπορείτε να προσθέσετε τα ίδια στοιχεία (Όνομα, Τίτλο και Περιγραφή) όπως περιγράφηκαν παραπάνω.

Τώρα καλέστε

osc up

και θα πάρετε ένα νέο κατάλογο με το όνομα του νέου πακέτου σας. Για να προσθέσετε αρχεία μέσω της γραμμής εντολών, απλά cd στο νέο κατάλογο, αντιγραφή των σχετικών αρχείων (συνήθως ένα αρχείο tar.xz και τα αρχεία υποστήριξης).

Τα openSUSE RPM πακέτα έχουν τις δικές τους οδηγίες κατασκευής σε ένα specfile. Δείτε τις οδηγίες πακεταρίσματος για το πως να το δημιουργήσετε. Μια ευκολότερη προσέγγιση είναι να αντιγράψετε και να προσαρμόσετε ένα specfile από κάποιο παρόμοιο πακέτο, ή μέσα από την ίδια την tar-αρχειοθήκη, αν είναι διαθέσιμο. Όταν τα αρχεία είναι έτοιμα καλέστε

osc add *

Αυτό θα μαρκάρει τα αρχεία στον κατάλογο για την επόμενη υποβολή. Για να τα υποβάλετε καλέστε

osc commit

Μια υποβολή αυτόματα εκκινεί την διαδικασία κατασκευής. Ενδεχομένως να θέλετε να καθυστερήσετε την υποβολή, μέχρι να μπορέσετε πρώτα να κατασκευάσετε επιτυχώς το πακέτο τοπικά, δείτε παρακάτω.

Βήμα Τρία – Επιλογή Στόχου για Κατασκευή

Τώρα πρέπει να επιλέξετε για ποιες διανομές (πχ openSUSE 11.3, Ubuntu 10.04 κλπ.) θα πρέπει να κατασκευαστούν τα πακέτα.

Διεπαφή ιστού: Στην καρτέλα "Repositories" στο έργο σας, κλικ στο add repositories και επιλέξτε μια από τις διαθέσιμες Διανομές και Αρχιτεκτονικές.

Γραμμή εντολών: Πρώτα πάρτε μια λίστα με τα διαθέσιμα αποθετήρια

osc ls

έπειτα αλλάξτε τα μεταδεδομένα του έργου σας:

osc meta prj -e home:<username>

και προσθέστε το αποθετήριο:

 <repository name="openSUSE_Factory">
   <path project="openSUSE:Factory" repository="standard" />
   <arch>x86_64</arch>
   <arch>i586</arch>
 </repository>

Το project μπορεί να είναι openSUSE:Factory, openSUSE:11.3, SUSE:SLE-11:SP1 και πάει λέγοντας. Το repository="standard" είναι μόνο για μελλοντικές επεκτάσεις (διακλαδώσεις (fork) ενός αποθετηρίου).

Βήμα Τέσσερα – Κατασκευή του πακέτου σας

Το πακέτο σας προγραμματίζεται για κατασκευή αυτόματα μετά την υποβολή του ή την αλλαγή κάποιων αρχείων. Αν κάποιο απαιτούμενο πακέτο ανακατασκευαστεί, και το δικό σας θα ανακατασκευαστεί αυτόματα.

Μπορείτε επίσης χειροκίνητα να ορίσετε μια ανακατασκευή αν το θέλετε:

osc rebuildpac <project> <package> [<repo> [<arch>]]

Με τα προαιρετικά ορίσματα <repo> και <arch>, η ανακατασκευή μπορεί να περιοριστεί σε ένα συγκεκριμένο αποθετήριο ή αρχιτεκτονική.

Αν το πακέτο σας ονομάζετε home:username, μπορείτε να βρείτε το έργο σας στο http://download.opensuse.org/repositories/home:/username/

Κατασκευάστε το πακέτο σας τοπικά

Μερικές φορές είναι γρηγορότερο να κατασκευάσετε το πακέτο σας στο δικό σας μηχάνημα αντί να περιμένετε τα αποτελέσματα από το Build Service. Το osc υποστηρίζει τοπικές κατασκευές πακέτων, αν φυσικά και το υλικό σας το υποστηρίζει (σε x86_64 μπορείτε να κατασκευάσετε για i586 και x86_64, σε i586 μόνο για i586).

Βεβαιωθείτε ότι έχετε τα πιο πρόσφατα πηγαία αρχεία

Χρησιμοποιήστε το osc checkout (osc co) ή osc up για να βεβαιωθείτε ότι έχετε την πιο πρόσφατη έκδοση του πηγαίου κώδικα.

Αν είναι έργο δε χρειάζεται να κάνετε checkout:

cd <κατάλογος_εργασίας_σας_με_το_obs>;
osc co <project> <package>

ή

cd <κατάλογος_εργασίας_σας_με_το_obs>/<project>;
osc co <package>

ή

cd <κατάλογος_εργασίας_σας_με_το_obs>/<project>/<package>; osc up

Εκτελέστε την τοπική κατασκευή

 osc build <platform> <arch> <specfile> [--clean|--noinit]

για παράδειγμα

~/obs/home:user/project # osc build openSUSE_11.4 x86_64 project.spec

Το osc θα συνδεθεί στον εξυπηρετητή αποθετηρίων και θα κατεβάσει τα απαραίτητα RPM στον κατάλογο προσωρινής μνήμης /var/tmp/osbuild-packagecache/plattform/repository/arch. (Επομένως αν έχετε ήδη ένα ολόκληρο αποθετήριο, μπορείτε να συνδέσετε τα RPM σε αυτόν τον κατάλογο για να αποφύγετε την υπερβολική κίνηση στο διαδίκτυο.)

Για παράδειγμα για το αποθετήριο του openSUSE_12.1 μπορείτε να χρησιμοποιήσετε το Retail Box DVD iso όπως παρακάτω:

 mount openSUSE-12.1.iso /mnt/ -o loop
 mkdir -p /var/tmp/osbuild-packagecache/openSUSE\:12.1/standard
 cp -r /mnt/suse/* /var/tmp/osbuild-packagecache/openSUSE:12.1/standard

Τώρα διορθώστε τις άδειες καθώς το DVD δεν είναι εγγράψιμο, αλλά το osc θα χρειαστεί να γράψει δεδομένα στην προσωρινή μνήμη:

 find /var/tmp/osbuild-packagecache/openSUSE:12.1 -type d -exec chmod 755 {} +
 find /var/tmp/osbuild-packagecache/openSUSE:12.1 -type f -exec chmod 644 {} +

Πακέτα τώρα μπορούν να κατασκευαστούν τοπικά κάπως έτσι:

 osc build openSUSE_12.1 i586 <some-package-name>.spec

Το osc θα δημιουργήσει ένα περιβάλλον chroot στο/var/tmp/build-root/ και θα ξεκινήσει την κατασκευή του πακέτου σας. Σε περίπτωση που έχετε μόνο μικρές αλλαγές (minor), μπορείτε να αποφύγετε την αναδημιουργία ολόκληρου του περιβάλλοντος κατασκευής με την επιλογή --noinit. Αν υποψιάζεστε ότι το περιβάλλον chroot σας είναι προβληματικό, μπορείτε να εκκινήσετε μια πλήρη ανακατασκευή με την επιλογή --clean. Μπορείτε να ρυθμίσετε τον κατάλογο chroot: δείτε τα σχόλια στο ~/.oscrc αρχείο σας.

Το osc θα αρνηθεί να εγκαταστήσει πακέτα από έργα που το σύστημά σας δεν εμπιστεύεται. Αυτό μπορεί να συμβεί όταν το πακέτο σας συνδέεται με κάποιο έργο υπό ανάπτυξη, αλλά το σύστημά σας δεν είναι ρυθμισμένο να χρησιμοποιεί εκείνο το αποθετήριο. Μπορείτε να πάρετε το απαραίτητο κλειδί GPG εκτελώντας:

sudo rpm --import - <<_END_KEY
$(osc signkey offending-project)
_END_KEY

Μετά την κατασκευή των πακέτων σε αυτό το περιβάλλον chroot, μπορείτε να τα βρείτε στο /var/tmp/build-root/home/abuild/rpmbuild/RPMS/ (παλαιότερες εκδόσεις του rpmbuild χρησιμοποιούν το /usr/src/packages/RPMS/.

Αν το πακέτο σας χρησιμοποιεί μια υπηρεσία μεταφόρτωσης σε κάποιο URL, ίσως να χρειαστεί να εκτελέσετε πρώτα την ακόλουθη εντολή:

zypper ar -r http://download.opensuse.org/repositories/openSUSE:/Tools/openSUSE_11.3/openSUSE:Tools.repo

Το πλήρες αρχείο καταγραφής της τοπικής κατασκευής σας αποθηκεύεται στο /var/tmp/build-root/.build.log.

Διόρθωση Σφαλμάτων στη Διαδικασία Τοπικής Κατασκευής

Ο κύριος λόγος για τον οποίο θα χρειαστείτε να μεταγλωττίσετε ένα νέο πακέτο για το openSUSE ή για οποιαδήποτε άλλη διανομή είναι για να βεβαιώσετε τη συμβατότητα σε περίπτωση που δεν έχει ήδη μεταγλωττιστεί για την έκδοση του δικού σας λειτουργικού συστήματος. Ωστόσο, με αυτόν τον τρόπο πιθανόν να αντιμετωπίσετε νέα λάθη κατά τη διαδικασία κατασκευής που θα χρειαστεί να διορθώσετε. Ο ευκολότερος τρόπος για να διορθώσετε λάθη είναι να κάνετε chroot στο περιβάλλον κατασκευής και να δημιουργήσετε τη διόρθωση εκεί. Ενδεχομένως να θελήσετε να χρησιμοποιήσετε το openroot αντί του chroot ώστε να αποκτήσετε πρόσβαση X11 και όλους τους άλλους απαραίτητους καταλόγους προσαρτημένους.

 osc chroot openSUSE_12.1 x86_64

ή παλιομοδίτικα

 chroot /var/tmp/build-root/
 cd /home/abuild/rpmbuild/BUILD/κατάλογος-του-πακέτου-σας
 ls
 ή:
 openroot /var/tmp/build-root/ 'cd /home/abuild/rpmbuild/ILD/κατάλογος-του-πακέτου-σας; ls; bash'
 ...
 exit

Εξαρτήσεις

Αν λαμβάνετε σφάλματα εξαρτήσεων κατά την κατασκευή, προσθέστε μια γραμμή με την εξάρτηση που λείπει, όπως αυτή:

BuildRequires: cmake libkde4-devel

Σε αυτή την περίπτωση, τα cmake και libkde4-devel θα εγκατασταθούν πριν την κατασκευή του πακέτου σας.

Εγκαταστήστε επιπλέον πακέτα στο περιβάλλον κατασκευής

Για αποσφαλμάτωση, μπορεί να χρειαστεί να εγκαταστήσετε επιπρόσθετα πακέτα στο τοπικό περιβάλλον κατασκευής για να αποσφαλματώσετε και να διορθώσετε προβλήματα που έχουν να κάνουν με την κατασκευή. Αυτό μπορεί να γίνει μέσω του αρχείου ~/.oscrc και της μεταβλητής extra-pkgs. Για παράδειγμα:

extra-pkgs = vim gdb strace valgrind

Προνόμια εγκατάστασης

Αν λαμβάνετε ένα μήνυμα σφάλματος όπως αυτό:

error: Bad exit status from /var/tmp/rpm-tmp.qrRAn2 (%install)

αυτό σημαίνει ότι το βήμα %install απέτυχε (και όλα τα προηγούμενα πήγαν καλά). Αυτό μπορεί να συμβαίνει λόγω ελλειπών δικαιωμάτων εγγραφής αν προσπαθείτε να το εγκαταστήσετε σε λάθος τοποθεσία. Σε αυτή την περίπτωση προσθέστε την ακόλουθη εντολή make install στο αρχείο spec σας:

make install DESTDIR=%buildroot

Υποβάλετε τη δουλειά σας πίσω στο OBS

Μόλις έχετε τον κατάλογο <package> σας όπως τον θέλετε, χρησιμοποιήστε τις παρακάτω εντολές για να στείλετε τη δουλειά σας πίσω στο OBS.

προσθέστε ένα νέο αρχείο στο πακέτο

osc add

αφαιρέστε ένα αρχείο από το πακέτο

osc rm

ενημερώστε την καταγραφή αλλαγών (πχ. *.changes)

osc vc

υποβάλετε τα ενημερωμένα αρχεία σας πίσω στο OBS

osc commit

Μπαλώματα (Patches)

Αν σκοπεύετε να μπαλώσετε κάποιο αρχείο, αντιγράψτε το πριν την επεξεργασία του στο .orig, δοκιμάστε ξανά το επιθυμητό βήμα στην διαδικασία κατασκευής μέχρι να πετύχει και μετά δημιουργήστε το ανάλογο μπάλωμα (patch) για αυτό. Για να κάνετε την κατασκευή πιο περιγραφική πρέπει να εισάγετε ένα "set -x" στο specfile σας κάνοντας το bash να απαριθμεί όλες τις εκτελούμενες εντολές (το set +x απενεργοποιεί την απαρίθμηση μετά).

diff -Pdpru /var/tmp/build-root/home/abuild/rpmbuild/BUILD/your-package-dir/Makefile.orig \
               /var/tmp/build-root/home/abuild/rpmbuild/BUILD/your-package-dir/Makefile \
               >/osc/home:user/your-package-dir/my.patch

Τώρα προσθέστε το μπάλωμα στο αρχείο .spec βάζοντας το "Patch67: my.patch" στην κεφαλίδα και στη συνέχεια αφήστε το να εφαρμοστεί στην κατάλληλη θέση (συνήθως στό %setup) κατά τη διαδικασία κατασκευής από το "%patch67 -p7" (το -p7 αφαιρεί επτά επίπεδα καταλόγων αν δεν έχετε επεξεργαστεί χεράτα τους καταλόγους αρχείων στην κεφαλίδα του αρχείου μπαλώματος.).

Μπορεί να σας φανεί ευκολότερο να χρησιμοποιήσετε ένα ειδικό πρόγραμμα για αυτόματη δημιουργία μπαλωμάτων όπως το Quilt.

osc co yourproject/yourpackage
cd yourproject/yourpackage
quilt setup -v *spec
cd yourpackage-*/
quilt push -a # apply old patches
quilt new yourpackage-version_fixbuild.patch
quilt edit src/foo.c
quilt refresh

Το foo-fixbuild.patch θα δημιουργηθεί αυτόματα στον γονεϊκό κατάλογο. Αν δουλεύετε σε ένα πακέτο που δεν έχει κάποια διόρθωση ήδη. Πρέπει να θυμηθείτε να αντιγράψετε τη διόρθωση από τον κατάλογο που έγινε στον κατάλογο του πακέτου. Επανεκτελέστε quilt setup για να πάρετε μια αρχική διόρθωση. Μπορείτε να αφαιρέσετε διορθώσεις από το αντίγραφο στο οποίο δουλεύετε με το quilt pop.

Ένα αρχείο παράδειγμα .quiltrc:

# Options passed to GNU diff when generating patches
QUILT_DIFF_OPTS="--show-c-function" 
# QUILT_DIFF_OPTS="" 
# Options passed to GNU patch when applying patches
#QUILT_PATCH_OPTS="--ignore-whitespace --unified-reject" 

# Options to pass to commands (QUILT_${COMMAND}_ARGS)
QUILT_PUSH_ARGS="--color=auto" 
QUILT_DIFF_ARGS="--color=auto" 
QUILT_REFRESH_ARGS="--backup -p0"
QUILT_PATCH_OPTS="--unified-reject-files --backup"

Βήμα Πέντε: Έλεγχος των αρχείων καταγραφής

Το buildservice παράγει ένα μεγάλο αρχείο καταγραφής για κάθε κατασκευή πακέτου.

Διεπαφή ιστού: Κλικ στο σύνδεσμο [Build Log] στην οθόνη του πακέτου.

Γραμμή εντολών: Έχετε κάποιες επιλογές ανάλογα με τις ανάγκες σας (η packagedir είναι προαιρετική αν είστε στον κατάλογο του πακέτου):

osc prjresults [packagedir]

Εμφανίζει τα συγκεντρωτικά αποτελέσματα κατασκευής ενός ολόκληρου έργου. Ή μπορείτε να κάνετε:

osc results [packagedir]

Εμφανίζει τα αποτελέσματα κατασκευής ενός μόνο πακέτου.

osc buildlog <platform> <arch>

Δείχνει το αρχείο καταγραφής ενός πακέτου (πρέπει να είστε στον κατάλογο του πακέτου).

Δημιουργήστε Pattern

Τα Pattern είναι αρχεία που περιλαμβάνουν μια λίστα από πακέτα μαζί με μια περιγραφή του ποια είναι η χρησιμότητά τους. Επιπρόσθετα το Build Service δημιουργεί αρχεία .ymp για κάθε δημιουργημένο pattern αποθετηρίου. Αυτά τα .ymp αρχεία μπορούν να χρησιμοποιηθούν για Εγκατάσταση με Ένα Κλικ από τους χρήστες.

Εν συντομία, τα pattern χρησιμεύουν για την εγκατάσταση ενός συνόλου λογισμικού για μια τυπική ανάγκη χωρίς τη δημιουργία εξαρτήσεων μεταξύ πακέτων.

Η υποβολή pattern είναι δυνατή με τη χρήση του api απευθείας, ή με το osc:

για να ανοίξετε ένα pattern στον $EDITOR (ή να το δημιουργήσετε αν δεν υπάρχει)

osc meta pattern -e <project> <pattern>

για να δείτε μια λίστα από υπάρχοντα pattern

osc meta pattern <project>

για να πάρετε ένα υπάρχον pattern

osc meta pattern <project> <pattern>

μπορείτε επίσης να υποβάλετε ένα υπάρχον αρχείο ως εξής:

osc meta pattern --file <local_file> <project> <pattern>

Για να το δοκιμάσετε: κάνοντας κλικ στο .ymp από τον konqueror πρέπει να εκκινήσει τον εγκαταστάτη, αν δεν έχετε τον konqueror εγκατεστημένο, μπορείτε να δοκιμάσετε να τον εκκινήσετε από το κέλυφος ως ένας απλός χρήστης:

/sbin/yast2 MetaPackageHandler http://download.opensuse.org/repositories/<project>/<SUSE_Factory or openSUSE_10.2>/<pattern>.ymp

Το ακόλουθο αρχείο είναι ένα παράδειγμα αρχείου pattern από το έργο KDE:KDE4. Μπορείτε να δείτε το δημιουργημένο αρχείο .ymp από εδώ.

<pattern
 xmlns="http://novell.com/package/metadata/suse/pattern"
 xmlns:rpm="http://linux.duke.edu/metadata/rpm"
>
    <name>KDE 4 Games</name>
    <summary>KDE 4 Games</summary>
    <description>A number of games for KDE 4.</description>
    <uservisible/>
    <category lang="en">Desktop Functions</category>
    <rpm:recommends>
      <rpm:entry name="kde4-kpat"/>
      <rpm:entry name="kde4-kmahjongg"/>
      <rpm:entry name="kde4-kmines"/>
      <rpm:entry name="kde4-kreversi"/>
      <rpm:entry name="kde4-ksudoku"/>
    </rpm:recommends>
    <rpm:suggests>
      <rpm:entry name="kde4-katomic"/>
      <rpm:entry name="kde4-kbattleship"/>
      <rpm:entry name="kde4-ksquares"/>
      <rpm:entry name="kde4-bovo"/>
      <rpm:entry name="kde4-kiriki"/>
      <rpm:entry name="kde4-kwin4"/>
      <rpm:entry name="kde4-kolf"/>
      <rpm:entry name="kde4-klines"/>
      <rpm:entry name="kde4-ksame"/>
      <rpm:entry name="kde4-lskat"/>
      <rpm:entry name="kde4-kgoldrunner"/>
      <rpm:entry name="kde4-kblackbox"/>
      <rpm:entry name="kde4-kbounce"/>
      <rpm:entry name="kde4-ktuberling"/>
      <rpm:entry name="kde4-knetwalk"/>
      <rpm:entry name="kde4-kjumpingcube"/>
      <rpm:entry name="kde4-kspaceduel"/>
      <rpm:entry name="kde4-konquest"/>
      <rpm:entry name="kde4-kshisen"/>
    </rpm:suggests>
</pattern>

Μερικές περιγραφές ετικετών (Tag):

Tag	Description
<rpm:requires> <rpm:entry name="example" /> </rpm:requires>	Requires το RPM example: αυτό το πακέτο πρέπει να εγκατασταθεί - αλλιώς το pattern δεν πληρείται.
<rpm:recommends> <rpm:entry name="example" /> </rpm:recommends>	Recommends το RPM example: αν είναι διαθέσιμο και όλες οι εξαρτήσεις αυτού του πακέτου ικανοποιούνται, το πακέτο θα μπορούσε να εγκατασταθεί. Αν το πακέτο δεν είναι διαθέσιμο, δεν υπάρχουν μηνύματα σφαλμάτων. Αν οι εξαρτήσεις του πακέτου δεν ικανοποιούνται, το πακέτο θα είναι ορατό αλλά δε θα εγκαθίσταται.
<rpm:suggests> <rpm:entry name="example" /> </rpm:suggests>	Suggests το RPM example: θα εμφανίζεται στο pattern αλλά δε θα εγκαθίσταται εξ ορισμού.

Ένα ολοκληρωμένο παράδειγμα μιας απλής αλλαγής

Σημείωση: Υπάρχουν τουλάχιστον άλλες δύο σελίδες στο wiki που τεκμηριώνουν τη ροή εργασίας διακλάδωσης/διόρθωσης/υποβολής μπαλώματος (branch/fix/submit patch):

Ο στόχος εδώ είναι να έχουμε ένα συγκεκριμένο παράδειγμα που μπορεί να χρησιμοποιηθεί ως εκπαιδευτικός οδηγός.

Προσοχή ΠΡΟΧΕΙΡΟ ΠΑΡΑΚΑΤΩ, δεν έχει ολοκληρωθεί ή ελεγχθεί

Μια συνηθισμένη διαδικασία είναι η διακλάδωση ενός υπάρχοντος πακέτου από κάποιο υπάρχον έργο, δημιουργία κάποιας αλλαγής και μετά επανένωση με το αρχικό πακέτο.

Τα βασικά βήματα είναι:

Διακλάδωση (Branch) του αρχικού πακέτου: "osc branch <original_project> <original_package>" Αυτό δημιουργεί ένα νέο κλαδί ανάπτυξης έργου που είναι αποκλειστικά για εσάς με την ονομασία home:<your_user_name>:branches:<original_project_name> και σε αυτό το έργο δημιουργεί ένα νέο πακέτο με το ίδιο όνομα όπως το αρχικό. Πρόκειται βασικά για μια αντιγραφή του αρχικού πακέτου.
Εξαγωγή του διακλαδωμένου πακέτου: "osc checkout home:<your_user_name>:branches:<original_project_name>/<original_package_name>" Αυτό μεταφορτώνει τα πηγαία αρχεία του διακλαδωμένου πακέτου από τον εξυπηρετητή σε ένα τοπικό υποκατάλογο με την ονομασία home:<your_user_name>:branches:<original_project_name>/<original_package_name>
Αλλαγή τοποθεσίας στον τοπικό υποκατάλογο: "cd home:<your_user_name>:branches:<original_project_name>/<original_package_name>" και ορισμός της συνηθισμένης προεπιλεγμένης umask "umask 0022"
Εργασία στο τοπικό αντίγραφο του πακέτου μέχρι να λειτουργήσει τοπικά:
1. Αλλαγή στα τοπικά πηγαία αρχεία (π.χ. επεξεργασία του αρχείου spec ή δημιουργία μιας διόρθωσης)
2. Τοπική κατασκευή
3. Εγκατάσταση του πακέτου τοπικά
4. Δοκιμή του εγκατεστημένου πακέτου
Ενημέρωση του αρχείου αλλαγών: "osc vc" Αυτό ανοίγει έναν επεξεργαστή κειμένου (συνήθως το 'vi') και δημιουργεί μια κατάλληλη κεφαλίδα για μια εισαγωγή αλλαγών RPM. Αν υπήρξε κάποια αναφορά σφάλματος πρέπει να αναφερθεί ως bnc#123456
Αν προστέθηκαν νέα αρχεία (π.χ. νέα διορθωτικά μπαλώματα) ή αρχεία που αφαιρέθηκαν (π.χ. απαρχαιωμένα διορθωτικά μπαλώματα), ενημερώστε την κατάσταση ελέγχου εκδόσεων των τοπικών πηγαίων αρχείων: "osc addremove" και ελέγξτε με το "osc status" ότι δεν υπάρχουν αρχεία με προβληματική κατάσταση ελέγχου έκδοσης όπως '?' ή '!'
Υποβολή των τοπικών αλλαγών των πηγαίων αρχείων στο διακλαδωμένο πακέτο: "osc commit" Αυτό ανεβάζει τα τοπικά πηγαία στο διακλαδωμένο πακέτο στον εξυπηρετητή και η διαδικασία αυτή εκκινεί αυτόματα την επανακατασκευή του διακλαδωμένου πακέτου.
Αναθεώρηση των αποτελεσμάτων κατασκευής του διακλαδωμένου πακέτου για όλα τα αποθετήρια κατασκευής που έχουν ενεργοποιηθεί για το αρχικό πακέτο: "osc results --verbose home:<your_user_name>:branches:<original_project_name> <original_package_name>" Για να δείτε τα αποθετήρια που έχουν ενεργοποιηθεί για τα οποία κατασκευάζεται το αρχικό πακέτο πάρτε τα αποτελέσματα κατασκευής του: "osc results <original_project> <original_package>"
Αν η ανακατασκευή του διακλαδωμένου πακέτου είναι σε κατάσταση "succeeded" για όλα τα αποθετήρια κατασκευής που έχουν ενεργοποιηθεί για το αρχικό πακέτο, δημιουργήστε ένα αίτημα υποβολής και επανένωσης του διακλαδωμένου πακέτου με το αρχικό: "osc submitrequest --message='<ένα σύντομο μήνυμα που περιγράφει τις αλλαγές σας μαζί το bnc#123456 αν υπάρχει κάποια αναφορά σφάλματος που ταιριάζει>' home:<your_user_name>:branches:<original_project_name> <original_package_name> <original_project> <original_package>" και κρατήστε τον αριθμό ID του αιτήματος.
Ανά τακτά χρονικά διαστήματα ελέγξτε τι συνέβη με το αίτημά σας: "osc request show <request_ID_number>" Αν χρειαστεί να έρθετε σε άμεση επικοινωνία με τους συντηρητές του αρχικού πακέτου το: "osc maintainer <original_project> <original_package>" εμφανίζει τα ονόματά τους και το "osc whois <user_name>" εμφανίζει πλήρες όνομα και email ενός χρήστη του buildservice.

Είναι κάμποσα τα βήματα, αλλά εύκολα συνηθίζονται.

Όλα αυτά προϋποθέτουν την ύπαρξη ενός λογαριασμού στο OBS. Αν όχι, πηγαίνετε και δημιουργήστε έναν στο http://build.opensuse.org/ και χρησιμοποιήστε το σύνδεσμο εισόδου πάνω δεξιά για να μπείτε. Το OBS χρησιμοποιεί το ίδιο σύστημα αυθεντικοποίησης όπως και η υπόλοιπη υποδομή του openSUSE (πχ bugzilla), οπότε είναι πιθανό να έχετε ήδη κάποιο λογαριασμό, απλά πρέπει να κάνετε μια είσοδο στο σύστημα για πρώτη φορά και ο λογαριασμός σας χρήστη στο OBS θα δημιουργηθεί αυτόματα.

Ορίστε κι ένα πραγματικό παράδειγμα:

Ρύθμιση μιας φοράς από τερματικό.

sudo zypper in osc
mkdir ~/obs

Έπειτα πρέπει να κάνετε μια διακλάδωση ενός πακέτου τοπικά.

cd ~/obs
umask 0022
osc branch security sleuthkit
osc co home:<your_user_name>:branches:security/sleuthkit
cd ~/obs/home:<your_user_name>:branches:security/sleuthkit

Τώρα πλέον που υπάρχει ήδη το πακέτο, τα πράγματα είναι εύκολα:

# αποσυμπίεση της αρχειοθήκης και άλλα μαγικά κόλπα
quilt setup sleuthkit.spec
# αλλαγή καταλόγου στα πηγαία
cd sleuthkit-3.2.3
# εφαρμογή όλων των διορθώσεων
quilt push -a
# προσθήκη νέας διόρθωσης
quilt new testing.patch
# προσθήκη αρχείου στη διόρθωση
quilt add some-file
vi <some-file>
# ή εναλλακτικά:
quilt edit <some-file>
# και τέλος
quilt refresh -p1
# αντιγραφή της διόρθωσης στον κατάλογο του έργου
cp patches/testing.patch .. 
# και τώρα τακτοποίηση και του αρχείου spec
cd ..
vi sleuthkit.spec
# Προσθήκη της διόρθωσης με την εισαγωγή του Patch0 στην περιοχή της κεφαλίδας και μιας %patch0 -p1 γραμμής στο τμήμα %prep

# Πείτε στο OBS ότι το πακέτο έχει πλέον κι ένα αρχείο ακόμα
osc add testing.patch
# ενημερώστε το αρχείο αλλαγών
osc vc -m "Fix some typos."
# και κατασκευάστε, εγκαταστήστε και ελέγξτε τη δουλειά σας
osc build
# διενέργεια μιας τοπικής εγκατάστασης.  Στο τέλος της εξόδου του osc build θα πρέπει να εμφανιστεί η πλήρης διαδρομή του αρχείου RPM
zypper in -f <full_path_to_rpm>
# επανάληψη μέχρι να μείνετε ευχαριστημένοι από το αποτέλεσμα. Αν το αποτέλεσμα δεν είναι καλό πάμε πίσω στην επεξεργασία με το quilt.
# στείλτε τις αλλαγές σας πίσω στο OBS
osc commit
# περιμένετε λίγο για να ολοκληρωθεί η κατασκευή των νέων πακέτων στο OBS
# ελέγξτε την κατάσταση της κατασκευής μέσω του WebUI για το διακλαδωμένο πακέτο σας
# Μόλις δημοσιευτεί, εγκαταστήστε το πακέτο RPM από το OBS και ελέγξτε ξανά
# υποβάλετε τις αλλαγές σας πίσω στο αρχικό πακέτο.  Αν υπάρχει κάποια εισαγωγή από τον bugzilla, βεβαιωθείτε ότι την αναφέρετε

Δείτε επίσης