openSUSE:Packaging guidelines

Πακετάρισμα

Γενικές Οδηγίες · Οδηγίες Ονοματοθεσίας · Οδηγίες Specfile · Οδηγίες Διορθώσεων · Οδηγίες Ασφάλειας · Οδηγίες RPM Ομάδων
Οδηγός για το Build Service · Κόλπα & Έξυπνες λύσεις · Οδηγός Ανεξαρτήτου Διανομής · Έλεγχοι πακεταρίσματος
Κατηγορίες μενού επιφάνειας εργασίας · Μακροεντολές RPM · Έτοιμοι κώδικες σεναρίων · Σενάρια εκκίνησης

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

• Είναι ευθύνη του αναθεωρητή να καταδείξει ειδικά προβλήματα με ένα πακέτο και του πακετά να ασχοληθεί με αυτά τα θέματα. Ο αναθεωρητής και ο πακετάς συνεργάζονται για να διαπιστώσουν τη σοβαρότητα των ζητημάτων – είτε εμποδίζουν ένα πακέτο είτε μπορούν να διορθωθούν αφού το πακέτο ανέβει στο αποθετήριο.
• Οι γραμμές καθοδήγησης είναι μια συλλογή από γνωστά ζητήματα και η σοβαρότητα που θα πρέπει να έχουν. Ενώ αυτές οι οδηγίες δε θα έπρεπε να αγνοούνται, δε θα πρέπει να ακολουθούνται και τυφλά. Αν νομίζετε ότι το πακέτο σας θα έπρεπε να εξαιρεθεί από κάποιους κανόνες, παρακαλώ αναφέρετε το θέμα στη λίστα ηλεκτρονικού ταχυδρομείου openSUSE-packaging.
• Παρακαλώ σημειώστε επίσης ότι, στο Build Service, πολλοί κανόνες θα εφαρμοστούν με το ζόρι, ή θα προειδοποιηθείτε, μετά από μια επιτυχή κατασκευή, από ένα εργαλείο που ονομάζεται rpmlint. Ο πακετάς θα έπρεπε πάντα να ελέγχει την έξοδό του για να ενημερωθεί για κοινά σφάλματα πακεταρίσματος και να λάβει και κάποιες ιδέες για το που το πακετάρισμα μπορεί να βελτιωθεί. Δείτε το Έλεγχοι Πακεταρίσματος για εξηγήσεις σχετικά με τις περισσότερες από τις προειδοποιήσεις του rpmlint. Η σελίδα επίσης περιέχει οδηγίες για το πως λανθασμένες προειδοποιήσεις μπορούν να κατασταλούν.

Γενικές οδηγίες

Υπάρχουν κάποιοι γενικοί κανόνες που πρέπει να ακολουθούνται.

Όχι συμπερίληψη προ-κατασκευασμένων δυαδικών ή βιβλιοθηκών

Όλα τα δυαδικά ή οι βιβλιοθήκες που συμπεριλαμβάνονται στα πακέτα openSUSE πρέπει να έχουν κατασκευαστεί από τον πηγαίο κώδικα που περιλαμβάνεται στο πηγαίο πακέτο. Αυτό είναι μια απαίτηση για τους ακόλουθους λόγους:

• Ασφάλεια: Προ-κατασκευασμένα δυαδικά και βιβλιοθήκες που δεν έχουν κατασκευαστεί από πηγαίο κώδικα μπορούν να περιλαμβάνουν οτιδήποτε, κακόβουλο ή επικίνδυνο περιεχόμενο, ή απλά να είναι εντελώς κατεστραμμένο. Επίσης, αυτά είναι λειτουργικά αδύνατο να μπαλωθούν και να διορθωθούν.
• Σημαιάκια μεταγλωττιστή: Προ-κατασκευασμένα δυαδικά και βιβλιοθήκες που δεν έχουν κατασκευαστεί από πηγαίο κώδικα πιθανόν να μην έχουν τα πρότυπα σημαιάκια μεταγλωττιστή για το openSUSE για ασφάλεια και βελτιστοποίηση.

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

• Είναι εκτελέσιμο; Αν ναι, πιθανότατα πρόκειται για δυαδικό.
• Περιέχει μια επέκταση από τις .so, .so.#, .so.#.# ή .so.#.#.#; Αν ναι, πιθανότατα πρόκειται για βιβλιοθήκη.
• Αν έχετε αμφιβολίες, ρωτήστε στη λίστα ηλεκτρονικού ταχυδρομείου openSUSE-packaging.

Πακέτα που απαιτούν συστατικά μη ανοιχτού λογισμικού για την κατασκευή τους επίσης δεν επιτρέπονται (πχ αν απαιτείται ιδιόκτητος μεταγλωττιστής).

Εξαιρέσεις

• Κάποια λογισμικά (συνήθως συσχετιζόμενα με μεταγλωττιστές ή περιβάλλοντα δια-μεταγλώττισης) δεν μπορούν να κατασκευαστούν χωρίς τη χρήση μιας προηγούμενης αλυσίδας εργαλείων ή περιβάλλοντος ανάπτυξης (ανοιχτού λογισμικού). Αν έχετε ένα πακέτο που ανήκει σε αυτήν την περίπτωση, επικοινωνήστε με την Επιτροπή Πακεταρίσματος openSUSE για έγκριση.
• Μια εξαίρεση γίνεται για δυαδικό firmware, εφόσον πληρεί τις τεκμηριωμένες απαιτήσεις: BinaryFirmware

Ομαδοποίηση πολλαπλών έργων

Τα πακέτα στο openSUSE θα πρέπει να λάβουν τη μεγαλύτερη δυνατή προσπάθεια για την αποφυγή πολλαπλών, ξεχωριστών, έργων upstream ομαδοποιημένων σε ένα ενιαίο πακέτο.

Οδηγίες για το Specfile

Οι κανόνες που εφαρμόζουν στο περιεχόμενο των specfiles βρίσκονται σε ένα ξεχωριστό έγγραφο που ονομάζεται Specfile guidelines.

Υποστήριξη αρχιτεκτονικής

Όλα τα πακέτα για το openSUSE πρέπει να μεταγλωττίζονται επιτυχώς και να κατασκευάζονται σε δυαδικά αρχεία RPM σε τουλάχιστον μια από τις υποστηριζόμενες αρχιτεκτονικές, οι οποίες είναι οι i586 και x86_64. Οι πακετάδες θα έπρεπε να κάνουν κάθε δυνατή προσπάθεια ώστε τα πακέτα να κατασκευάζονται και για τις δυο αρχιτεκτονικές. Κώδικας ανεξάρτητος περιεχομένου (δηλ, κώδικας που δε χρειάζεται να μεταγλωττιστεί ή να κατασκευαστεί) και ανεξάρτητος πλατφόρμας (noarch) είναι αξιοσημείωτες εξαιρέσεις.

Μετακινούμενα πακέτα

Η χρήση των ευκολιών RPM για τη δημιουργία μετακινήσιμων (relocatable) πακέτων δεν προτείνεται. Είναι δύσκολο να τα κάνετε να δουλέψουν σωστά, αδύνατο να χρησιμοποιηθούν από τον εγκαταστάτη ή το zypper και το yast, και γενικά δεν είναι χρήσιμα αν ακολουθηθούν οι άλλες οδηγίες πακεταρίσματος. Ωστόσο, στην απίθανη περίπτωση που έχετε ένα καλό λόγο για να κάνετε ένα πακέτο relocatable, ΠΡΕΠΕΙ να δηλώσετε την πρόθεσή σας και την αιτιολόγηση στην αίτηση για αναθεώρηση του πακέτου.

---

Νομικά

Απαγορευμένο λογισμικό

Εφαρμογές (ή άλλο λογισμικό) που αναφέρεται στη μαύρη λίστα του Build Service απαγορεύεται να πακεταριστούν.

Αδειοδότηση

Η αδειοδότηση πρέπει να είναι συμβατή κατά OSI. Η λίστα των Open Source Licenses (Licenses by Name) απαριθμεί αυτές τις άδειες που έχουν εγκριθεί από το Open Source Initiative (OSI). Το openSUSE και πολλε άλλες διανομές προτυποποίησαν ένα κοινό σύνολο συντομογραφιών αδειών μέσω του έργου SPDX. Αυτό φαίνεται να το υιοθέτησε και το OSI, επίσης.

Χρησιμοποιήστε τις προτυποποιημένες συντομογραφίες ονομάτων της λίστας αδειών του OSI (ή του SPDX). Επιπλέον, το SPDX παρουσίασε μια μίνι-σύνταξη στη δήλωση πολλαπλών αδειών. Για παράδειγμα, αν το λογισμικό που θέλετε να πακετάρετε είναι κάτω από δύο άδειες: την GPL έκδοση 2 ή νεώτερη και την MIT, χρησιμοποιήστε αυτό στο αρχείο spec σας:

License:     GPL-2.0+ or MIT

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

Κώδικας vs Περιεχόμενο

Είναι σημαντικό να κάνετε διάκριση μεταξύ του εκτελέσιμου κώδικα σε υπολογιστή και του περιεχομένου. Ενώ ο κώδικας επιτρέπεται (υποθέτοντας, φυσικά, ότι έχει μια συμβατή με ανοιχτό λογισμικό άδεια, δεν υπάρχει νομική αμφιβολία κλπ), μόνο κάποια είδη περιεχομένου επιτρέπονται. Ο κανόνας είναι ο εξής:

Αν το περιεχόμενα ενισχύει την εμπειρία του χρήστη, τότε είναι ένταξη να πακεταριστεί στο openSUSE. Αυτό σημαίνει, για παράδειγμα, ότι πράγματα όπως: γραμματοσειρές, θέματα, εικόνες clipart, και wallpaper είναι OK.

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

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

Μερικά παραδείγματα επιτρεπτού περιεχομένου:

• Εικόνες Clipart για χρήση σε σουίτες γραφείου
• Wallpaper (μη-προσβλητικά, χωρίς διακρίσεις, με άδεια ελεύθερης αναδιανομής)
• Γραμματοσειρές (κάτω από μια άδεια ανοιχτού λογισμικού, χωρίς αμφιβολίες ιδιοκτησίας/νομικές)
• Επίπεδα παιχνιδιών δε θεωρούνται περιεχόμενα, αφού παιχνίδια χωρίς επίπεδα δεν θα ήταν λειτουργικά.
• Ήχος ή γραφικά που περιλαμβάνονται στην αρχειοθήκη πηγαίου κώδικα που το πρόγραμμα ή το θέμα χρησιμοποιεί (ή η τεκμηρίωση χρησιμοποιεί) είναι αποδεκτά.
• Περιεχόμενο μουσικής ή ήχου παιχνιδιών είναι επιτρεπτό, εφόσον το περιεχόμενο μπορεί να αναδιανεμηθεί ελεύθερα χωρίς περιορισμούς.
• Αρχεία παραδειγμάτων που συμπεριλαμβάνονται στην αρχειοθήκη πηγαίου δε θεωρούνται περιεχόμενο.

Μερικά παραδείγματα περιεχομένου που δεν επιτρέπονται:

• Αρχεία τέχνης βιβλίων Comic
• Θρησκευτικά κείμενα
• Αρχεία mp3 (επιβαρύνονται με ευρεσιτεχνίες)

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

---

Χαρακτηριστικά πακέτων

Σενάρια Init

• Σενάρια εκκίνησης SystemV-style υποστηρίζονται στο openSUSE. Υπάρχουν λεπτομερείς οδηγίες για SysV-style initscripts στο openSUSE:Packaging_init_scripts.
• Αρχεία μονάδων του systemd (openSUSE από 12.1 και μετά). Αναλυτικές οδηγίες είναι διαθέσιμες στο openSUSE:Systemd_packaging_guidelines.

Αρχεία Επιφάνειας Εργασίας

Αν ένα πακέτο περιέχει μια εφαρμογή GUI, τότε χρειάζεται να συμπεριλάβει κι ένα κατάλληλα εγκατεστημένο αρχείο .desktop. Για τους σκοπούς αυτών των οδηγιών, μια εφαρμογή GUI ορίζεται ως οποιαδήποτε εφαρμογή που σχεδιάζει ένα παράθυρο X και τρέχει από αυτό το παράθυρο. Εγκατεστημένα αρχεία .desktop ΠΡΕΠΕΙ να ακολουθούν τα desktop-entry-spec, με ιδιαίτερη προσοχή να αφιερώνεται στην ορθή χρήση των καταχωρήσεων Name, GenericName, Categories και StartupNotify.

Ετικέτα Icon στα αρχεία Desktop

Η ετικέτα icon πρέπει να είναι το όνομα βάσης (basename) του(ων) αρχείου(ων) icon , γιατί επιτρέπει τη θεματοποίηση των icon:

• Icon=comical

Θεωρεί .png εξ ορισμού, έπειτα δοκιμάζει .svg και τελικά .xpm.

Δημιουργία αρχείων .desktop

Αν το πακέτο δεν περιλαμβάνει ήδη και εγκαθιστά το δικό του αρχείο .desktop, πρέπει να φτιάξετε το δικό σας, και να το συμπεριλάβετε ως πηγή (πχ Source3: %name.desktop). Τα περιεχόμενα ενός δείγματος αρχείου .desktop (comical.desktop) είναι:

[Desktop Entry]
Name=Comical
GenericName=Comic Archive Reader
Comment=Open .cbr & .cbz files
Exec=comical
Icon=comical
Terminal=false
Type=Application
Categories=Graphics;

Χρήση της %suse_update_desktop_file

Δεν είναι αρκετό απλά να συμπεριλάβετε το αρχείο .desktop στο πακέτο. ΠΡΕΠΕΙ να εκτελεστεί το %suse_update_desktop_file στο τμήμα %install, και να υπάρχει και το BuildRequires: update-desktop-files στη λίστα, για να διασφαλιστεί η ασφάλεια του αρχείου .desktop και η συμβατότητα στο spec-compliance.Η %suse_update_desktop_file ΠΡΕΠΕΙ να χρησιμοποιηθεί αν το πακέτο δεν εγκαθιστά το αρχείο ή υπάρχουν επιθυμητές αλλαγές στο αρχείο .desktop (όπως προσθήκη/αφαίρεση κατηγοριών κλπ). Μερικά παραδείγματα χρήσης:

• έλεγχος αρχείου desktop

%suse_update_desktop_file %{name}

• εγκατάσταση αρχείου desktop και αλλαγή κατηγοριών

%suse_update_desktop_file -r %{name} System Utility Core GTK FileManager

Χρήστες και Ομάδες

Σημειώστε ότι για την ώρα, πρωτίστως απευθυνόμαστε στην περίπτωση όπου η χαρτογράφηση από τα ονόματα χρηστών/ομάδων σε uids/gids αποφασίζεται δυναμικά από το σύστημα κατά την εγκατάσταση του πακέτου. Μερικές επιλογές για διαχειριστές συστημάτων για να κάνουν αυτή τη χαρτογράφηση στατική ακόμα και όταν τα scriptlets των πακέτων χρησιμοποιούν ένα δυναμικό σχήμα συζητούνται παρακάτω, και ερευνώνται περισσότερο, συμπεριλαμβανομένων των δυνατοτήτων να γίνει η χαρτογράφηση στατική την ώρα της κατασκευής.

Για να δημιουργείτε χρήστες και ομάδες στα πακέτα, χρησιμοποιείστε:

Requires(pre): pwdutils

[...]

%pre
getent group GROUPNAME >/dev/null || groupadd -r GROUPNAME
getent passwd USERNAME >/dev/null || useradd -r -g GROUPNAME -d HOMEDIR -s /sbin/nologin -c "user for PACKAGENAME" USERNAME
exit 0

[...]

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

Λογαριασμοί χρηστών που δημιουργούνται από πακέτα σπάνια χρησιμοποιούνται για διαδραστικά logons, και συνεπώς γενικά θα πρέπει να χρησιμοποιούν τα /bin/false ή /sbin/nologin ως κέλυφος χρήστη.

Το exit 0 στο τέλος θα αποτελέσει στο %pre scriptlet να ολοκληρώσει επιτυχώς ακόμα κι αν η δημιουργία χρήστη/ομάδας αποτύχει για κάποιο λόγο. Αυτό δεν είναι και το καλύτερο, αλλά έχει τον λιγότερο κίνδυνο να προκαλέσει μια ευρύτερη ζημιά στο σύστημα από το να του επιτραπεί η αποτυχία. Αν ο χρήστης/ομάδα δεν είναι διαθέσιμος κατά το payload του πακέτου ξεπακετάρεται, το rpm θα ρίξει τα αρχεία στην κατοχή του root.

Το getent εκτελείται πριν το groupadd/useradd, για να ελέγξει αν ο χρήστης/ομάδα που πρόκειται να δημιουργηθεί υπάρχει ήδη στο σύστημα, και αν ναι, παραλείπει τη δημιουργία. Αυτό συμβαίνει για να δοθεί η δυνατότητα στους τοπικούς διαχειριστές του συστήματος να δημιουργήσουν το χρήστη/ομάδα από πριν χειροκίνητα, στην περίπτωση που επιθυμούν να αποδώσουν ένα προκαθορισμένο στατικό UID/GID mapping για αυτούς τους χρήστες.

Οι groupadd/useradd στο %pre εκτελούνται πάντα – και στις αρχικές εγκαταστάσεις και στις αναβαθμίσεις. Αυτό επιτυγχάνεται κάνοντας τους ελέγχους getent από πάνω, και θα διορθώσει τα πράγματα αν ο χρήστης/ομάδα εξαφανίστηκαν μετά την αρχική εγκατάσταση του πακέτου προς αναβάθμιση (ακριβώς όπως οι άδειες των αρχείων reset κατά τις αναβαθμίσεις κλπ).

Οι χρήστες ή οι ομάδες που δημιουργούνται από πακέτα ποτέ δεν αφαιρούνται. Δεν υπάρχει κάποιος ασφαλής τρόπος για τον έλεγχο αν υπάρχουν αρχεία που ανήκουν σε αυτούς τους χρήστες/ομάδες έχουν ξεμείνει πίσω – και ακόμα και αν υπήρχε, τι θα τα κάναμε; Αφήνοντας τέτοια αρχεία πίσω με ιδιοκτησία που δείχνει σε ανύπαρκτους χρήστες/ομάδες μπορεί να αποτελέσει σε θέματα ασφαλείας όταν ένας σημασιολογικά άσχετος χρήστης/ομάδα δημιουργηθεί αργότερα και ξαναχρησιμοποιήσει το UID/GID. Επίσης, σε μερικά setups, η διαγραφή των χρηστών/ομάδων μπορεί να μην είναι δυνατή ή/ούτε επιθυμητή, για παράδειγμα, όταν χρησιμοποιούμε μια διαμοιραζόμενη απομακρυσμένη βάση δεδομένων. Η εκκαθάριση των μη χρησιμοποιούμενων χρηστών/ομάδων αφήνεται στους διαχειριστές συστημάτων να την αναλάβουν αν την επιθυμούν.

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

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

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

Δείτε το Packaging Patches guidelines.

Υποστήριξη πολλαπλών εκδόσεων ενός πακέτου

Δείτε το Υποστήριξη εγκατάστασης πολλαπλών εκδόσεων πακέτων

---

Άδειες

  http://en.opensuse.org/openSUSE:Accepted_licences
  http://license.opensuse.org

---

Τύποι πακέτων

Μερικές εφαρμογές έχουν ειδικές οδηγίες γραμμένες για αυτές, που βρίσκονται στις δικές τους σελίδες στην ιεραρχία Πακετάρισμα/.

Debuginfo

Τα πακέτα θα πρέπει να παράγουν χρήσιμα -debuginfo πακέτα, ή ρητά να τα απενεργοποιούν όταν δεν είναι δυνατό να δημιουργηθεί κάποιο χρήσιμο, αλλά το rpmbuild θα το κατασκεύαζε ούτως ή άλλως. Οποτεδήποτε ενα πακέτο -debuginfo απενεργοποιείται ρητά, μια εξήγηση με το γιατί συμβαίνει κάτι τέτοιο απαιτείται στο specfile. Τα πακέτα Debuginfo συζητούνται λεπτομερέστερα σε ένα ξεχωριστό έγγραφο, [1].

Γραμματοσειρές

Γραμματοσειρές στη μορφή γενικού-σκοπού όπως οι Type1, OpenType TT (TTF) ή OpenType CFF (OTF) υπόκεινται σε ειδικές οδηγίες, και δε θα έπρεπε ποτέ να πακεταριστούν σε έναν ιδιωτικό κατάλογο εφαρμογής αντί των ευρύτερων αποθετηρίων γραμματοσειρών συστήματος.

Παιχνίδια

Το πώς να πακετάρετε παιχνίδια εξηγείται στο openSUSE:Packaging_Games.

Go

Το πώς να πακετάρετε λογισμικό της Go εξηγείται στο openSUSE:Packaging_Go.

Java

Το πώς να πακετάρετε λογισμικό Java εξηγείται στο openSUSE:Packaging_Java

Perl

Το πώς να πακετάρετε λογισμικό Perl εξηγείται στο openSUSE:Packaging_Perl

PHP

Το πώς να πακετάρετε λογισμικό PHP εξηγείται στο openSUSE:Packaging_PHP

Python

Το πώς να πακετάρετε λογισμικό Python εξηγείται στο openSUSE:Packaging_Python

Ruby

Το πώς να πακετάρετε λογισμικό Ruby εξηγείται στο openSUSE:Packaging_Ruby

wxWidgets

Το πώς να πακετάρετε λογισμικό wxWidgets εξηγείται στο openSUSE:Packaging_wxWidgets

Βιβλιοθήκες

Στατικές Βιβλιοθήκες

Πακέτα που περιλαμβάνουν βιβλιοθήκες θα έπρεπε να εξαιρούν τις στατικές όπου είναι αυτό δυνατόν (π.χ. Ενεργοποιώντας το διακόπτη --disable-static). Στατικές βιβλιοθήκες θα πρέπει να περιλαμβάνονται μόνο σε εξαιρετικές περιπτώσεις. Εφαρμογές που συνδέονται με βιβλιοθήκες θα έπρεπε, όσο είναι αυτό δυνατόν, να συνδέονται με τις κοινόχρηστες, όχι τις στατικές τους εκδόσεις.

Αρχεία του Libtool, και αρχεία foo.la, δε θα έπρεπε να συμπεριλαμβάνονται. Πακέτα που χρησιμοποιούν το libtool θα τα εγκαταστήσουν εξ ορισμού ακόμα και αν ενεργοποιήσετε το --disable-static, επομένως μπορεί να χρειαστεί να τα αφαιρέσετε πριν το πακετάρισμα. Εξαιτίας σφαλμάτων σε προηγούμενες εκδόσεις του libtool ή σφαλμάτων σε προγράμματα που το χρησιμοποιούν, υπάρχουν περιπτώσεις όπου δεν είναι δυνατή οι αφαίρεση των αρχείων *.la χωρίς την τροποποίηση του προγράμματος. Στις περισσότερες περιπτώσεις, είναι αρκετά εύκολο να δουλέψετε με το upstream για να διορθώσετε τέτοια ζητήματα. Σημειώστε ότι αν αναβαθμίζετε μια βιβλιοθήκη σε μια σταθερή διάθεση του openSUSE και το πακέτο περιέχει αρχεία *.la, η αφαίρεσή τους θα πρέπει να αντιμετωπιστεί ως μια αλλαγή στο API/ABI, με άλλα λόγια, η αφαίρεσή τους αλλάζει τη διεπαφή που η βιβλιοθήκη δίνει στον υπόλοιπο κόσμο και δε θα πρέπει να ληφθεί ελαφρά υπόψη.

Εξαίρεση

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

Στατικές βιβλιοθήκες πρέπει να τοποθετούνται μέσα σε ένα *-devel-static υποπακέτο, το οποίο Requires το *-devel υποπακέτο. Διαχωρίζοντας τις στατικές βιβλιοθήκες από τα άλλα αρχεία ανάπτυξης στο *-devel μας επιτρέπει να παρακολουθούμε αυτή τη χρήση ελέγχοντας ποια πακέτα BuildRequire το πακέτο *-devel-static. Ο σκοπός είναι ότι, οποτεδήποτε είναι αυτό δυνατό, τα πακέτα θα πάνε από τη χρήση αυτών των στατικών βιβλιοθηκών στη χρήση των κοινόχρηστων. Όταν ένα πακέτο παρέχει μόνο στατικές βιβλιοθήκες, παραλείψτε το Requires στο υποπακέτο *-devel. Πακέτα που ρητά χρειάζονται να συνδεθούν στην στατική έκδοση πρέπει να τότε να BuildRequire: foo-devel-static, ώστε η χρήση να μπορεί να παρακολουθείται.

Αν (και μόνο αν) ένα πακέτο έχει κοινόχρηστες βιβλιοθήκες οι οποίες απαιτούν στατικές για να είναι λειτουργικές, οι στατικές βιβλιοθήκες μπορούν να συμπεριληφθούν στο υποπακέτο *-devel. Το υποπακέτο devel πρέπει να έχει ένα εικονικό Provide για το πακέτο *-devel-static, και τα πακέτα που εξαρτώνται από αυτό πρέπει να BuildRequire το *-devel-static πακέτο.

Διπλοεγγραφές βιβλιοθηκών συστήματος

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

Εφαρμογές Ιστού

Εφαρμογές ιστού που πακετάρονται στο openSUSE πρέπει να βάζουν το περιεχόμενό τους στο /srv/www/%name και ΟΧΙ στο /var/www. Αυτό γίνεται επειδή:

• Το /var υποτίθεται ότι περιέχει ποικίλα αρχεία δεδομένων και καταγραφών. Το /srv/www είναι πολύ πιο κατάλληλο για αυτή τη δουλειά.
• Οι χρήστες μπορεί να έχουν ήδη περιεχόμενα στο /var/www, και δε θέλουμε κάποιο πακέτο του openSUSE να κάτσει πάνω από αυτά.
• Το /var/www δεν ορίζεται πλέον από το Filesystem Hierarchy Standard.

Vala

Πώς να εντοπίσετε την έκδοση του Vala στο specfile

Υποθέτουμε ότι δεν κατασκευάζετε το Vala εσείς. Σε αυτή την περίπτωση, η έκδοση του Vala ορίζεται από εσάς και μπορεί απλά να γίνει με τη χρήση της ετικέτας %{version}, δεν υπάρχει κανένα πρόβλημα. Εδώ αντιμετωπίζουμε μια τέτοια δυσάρεστη κατάσταση:

Το πακέτο είναι κατασκευασμένο με το Vala, και κατασκευάζεται καλά με όλες τις εκδόσεις του Vala (Οπότε δε χρειάζεται να χρυσώσετε τον κρίνο με την ετικέτα BuildRequires: vala >= 0.14). Ωστόσο πρέπει να εντοπίσετε και να χρησιμοποιήσετε τον αριθμό έκδοσης του Vala.

Εδώ το Build Service τα βρίσκει σκούρα. Προς το παρόν, το Vala δεν μπορεί απλά να συμπεριληφθεί με το BuildRequires: vala και να εξάγει την έκδοσή του απλά και αφελή με αυτόματες ετικέτες όπως %{py_ver} ή %{perl_version} όπως κάνει η Perl ή η Python. Μερικά πακέτα πρέπει να ξέρουν τον αριθμό του Vala για να κάνουν τη δουλειά τους σωστά (πχ.., το Babl ή το Gegl θα εγκαταστήσουν το αρχείο .vapi στο /usr/share/vala εξ ορισμού, αλλά αυτός ο κατάλογος δεν έχει καμία σημασία σε ένα πρότυπο σύστημα openSUSE. Ωστόσο, το openSUSE χρησιμοποιεί έναν κατάλογο με επίθεμα το αριθμό έκδοσης του Vala /usr/share/vala-0.14. Τώρα είναι θέμα του πακετά να κάνει τη μεταφορά από τον προεπιλεγμένο κατάλογο του πακέτου στον ορισμένο κατάλογο του openSUSE).

Φυσικά θα μπορούσατε, χρησιμοποιώντας την ετικέτα %if 0?{%suse_verion} >= 1140, να τα μεταφέρετε στον κατάλογο που περιέχει το επίθεμα του αριθμού της έκδοσης του Vala, που είναι εγκατεστημένο εξ ορισμού στην έκδοση 1140 του openSUSE. Αλλά θα κάνει το specfile σας τεράστιο και μη συντηρήσιμο (πρέπει να προσθέσετε ένα τέτοιο τμήμα σχεδόν σε όλες τις εκδόσεις του openSUSE).

Τώρα χρησιμοποιούμε την ορισμένη συνάρτηση %define στο specfile，ως ακολούθως：

 #import Vala dependency 
 BuildRequires: vala
 #define a function to export Vala's version number
 %define vala_version %(rpm -q --queryformat='%{VERSION}' vala | sed 's/\.[0-9]*$//g')

Χρησιμοποιούμε το rpm -q --queryformat='%{VERSION}' vala για να φέρουμε τον πλήρη αριθμό έκδοσης του Vala 0.14.0, που εγκαθίσταται με έναν πρότυπο τρόπο RPM πριν ξεκινήσει η διαδικασία κατασκευής, για αυτό τέτοιος κώδικας δουλεύει. Και στη συνέχεια χρησιμοποιούμε την εντολή κελύφους sed με τη δύναμη του Regex για να κόψουμε το επίθεμα .0 και να εξάγουμε το αποτέλεσμα σε μια μεταβλητή vala_version, που μπορεί εύκολα να κληθεί με το %{vala_version}. πχ:

 #create a new directory. -pv means export directories it made into logfile for futher debug 
 #and create it automatically if the parent directory does not exist.
 %{__mkdir} -pv %{buildroot}%{_datadir}/vala-%{vala_version}/
 #move the files
 %{__mv} %{buildroot}%{_datadir}/vala/* %{buildroot}%{_datadir}/vala-%{vala_version}/
 #delete the original folder
 %{__rm} -rf %{buildroot}%{_datadir}/vala/

Ακόμα και στο τμήμα %files θα μπορούσατε να χρησιμοποιήσετε:

 %dir %{_datadir}/vala-%{vala_version}/
 %{_datadir}/vala-%{vala_version}/*

για να απλοποιήσετε το specfile σας.

Επειδή κάθε αρχείο κάτω από το %{buildroot} θα πακεταριστεί ιεραρχικά στο τελικό RPM που θα εξαχθεί, τώρα η φιλικότητά σας προς το χρήστη ως πακετάς παίρνει +1.