openSUSE:Packaging Patches guidelines

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

Σημείωση Patch (markup) (επίσης ονομάζεται και "Βάζοντας ετικέτες" (Ετικετάροντας)

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

  • Fixes: Αυτές είναι κανονικές διορθώσεις και χωρίζονται σε δύο κατηγορίες:
    • Διορθώσεις για πράγματα που έχουν να κάνουν ειδικά με το openSUSE, πράγματα για τα οποία οι συντηρητές στο upstream δεν ενδιαφέρονται.
    • Διορθώσεις για πράγματα που έχουν να κάνουν ειδικά με το SLE, πράγματα για τα οποία οι συντηρητές στο upstream δεν ενδιαφέρονται και δε χρειάζονται στο openSUSE.
    • Διορθώσεις για τα πηγαία στο upstream που θα έπρεπε να ανεβούν και εκεί.
  • νέα χαρακτηριστικά που προστίθενται στα πακέτα, επίσης χωρίζονται σε δυο κατηγορίες:
    • Χαρακτηριστικά για πράγματα που έχουν να κάνουν ειδικά με το openSUSE (ενσωμάτωση του AppArmor, για παράδειγμα) και δεν ενδιαφέρουν τους συντηρητές στο upstream.
    • Χαρακτηριστικά για πράγματα που έχουν να κάνουν ειδικά με το SLE και δεν ενδιαφέρουν τους συντηρητές στο upstream ούτε το openSUSE.
    • Χαρακτηριστικά που θα έπρεπε να ανεβούν στο upstream. Κάθε φορά που γράφουμε ένα νέο χαρακτηριστικό αυτού του είδους, είναι σημαντικό να συντονιστούμε με τους συντηρητές στο upstream. Με αυτόν τον τρόπο, μπορούμε να αναπτύξουμε κάτι το οποίο θα γίνει δεκτό στο upstream χωρίς αλλαγές. Όταν ένα χαρακτηριστικό ολοκληρωθεί, θέλει πολύ κόπο να το ξαναδουλέψουμε για να φτάσει σε μια αποδεκτή μορφή από τους συντηρητές στο upstream. Συνεπώς, είναι καλύτερο να ξέρουμε από την αρχή ακριβώς τι θα περίμεναν οι συντηρητές στο upstream.


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

# PATCH-FIX-OPENSUSE fix-for-opensuse-specific-things.patch [bnc#123456]
Patch1: fix-for-opensuse-specific-things.patch
# PATCH-FIX-SLE fix-for-sle-specific-things.patch [bnc#123456]
Patch2: fix-for-sle-specific-things.patch
# PATCH-FIX-UPSTREAM fix-for-upstream-sources.patch [bnc#123456]
Patch3: fix-for-upstream-sources.patch
# PATCH-FEATURE-OPENSUSE feature-for-opensuse-specific-things.patch [bnc#123456]
Patch4: feature-for-opensuse-specific-things.patch
# PATCH-FEATURE-SLE feature-for-sle-specific-things.patch [bnc#123456]
Patch5: feature-for-sle-specific-things.patch
# PATCH-FEATURE-UPSTREAM feature-for-upstream.patch [bnc#123456]
Patch6: feature-for-upstream.patch

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

# PATCH-NEEDS-REBASE old-patch.patch [bnc#123456] -- Does something old.  Was: PATCH-FEATURE-OPENSUSE
Patch7: old-patch.patch
[...]
# %patch7


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

Αυτό είναι:

# PATCH-{FIX|FEATURE}-{OPENSUSE|SLE|UPSTREAM} name-of-file.patch bnc#[0-9]* εσείς@example.com -- αυτή η διόρθωση κάνει τα πράγματα καταπληκτικά

Αν υπάρχουν σχετικά σφάλματα στο Novell ή σε άλλους bugzilla, παρακαλώ προσθέστε τα, θα μας βοηθήσει να λάβουμε πιο ακριβή πληροφόριση. Αν υπάρχουν δύο ή περισσότερα διαθέσιμα τότε είναι προτιμότερο να τα απαριθμήσετε και τα δύο (ή περισσότερα).

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

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

  • Αν μια διάθεση είναι επικείμενη, δημιουργήστε ένα bug για αυτή. Αυτό είναι συνήθως απαιτούμενο, και ακόμα και να μην ήταν, είναι το σωστό.
  • Αν μια διάθεση έχει δρόμο ακόμα μπροστά της και το σφάλμα έχει ήδη διορθωθεί στο upstream, σημειώστε στο σχόλιο ότι είναι ήδη διορθωμένο στο SVN (ή οπουδήποτε) και το patch θα φύγει στην επόμενη αναβάθμιση.

Ονομασία Patch

Όλες οι νέες διορθώσεις πρέπει να τελειώνουν με την επέκταση '.patch'.

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

ΜΗΝ χρησιμοποιείτε τη μακροεντολή %{version} στην γραμμή Patch:, ορίστε τον αριθμό έκδοσης χεράτα. Η χρήση της μακροεντολής:

  • προκαλεί πολλές μετονομασίες σε ενημερώσεις έκδοσης
  • καθιστά εύκολη την παράβλεψη patch που δε χρειάζονται πλέον
  • καθιστά δύσκολο τον προσδιορισμό της τελευταίας φοράς που το patch πειράχτηκε
  • καθιστά εύκολο το να βρεθεί πότε το patch χάλασε (αρχαιολογία πακέτων)

Εξαίρεση: patch που διορθώνουν προειδοποιήσεις που εξάγει ο μεταγλωττιστής λόγω ψευδούς κώδικα συχνά ονομάζονται 'abuild.patch'.

Το προτιμώμενο patchlevel είναι το -p1 καθώς επιτρέπει την πιο άμεση εισαγωγή/χρήση εργαλείων όπως το quilt.


Τωρινό σύνολο συντομογραφιών

Για να αποφύγουμε τη σύγχυση και το διπλό φορτίο, η αναφορά σε άλλα bugzillas επιτρέπεται. Ορίστε μερικές συντομεύσεις για συχνά χρησιμοποιούμενους bugzilla, που θα έπρεπε να προστεθούν πριν από το "#" του αριθμού του bugzilla. Σημειώστε ότι δεν υπάρχει κενό μεταξύ της συντόμευσης και του αριθμού του bugzilla.

Shortcut Bugzilla-URL Example
Boost https://svn.boost.org/trac/boost/report (boost#123456)
CVE entries (παρακαλώ προσθέστε τον αριθμό, ακόμα και αν υπάρχει επιπλέον bugzilla για αυτές) http://cve.mitre.org (CVE-2009-0067)
CPAN Public Bug Tracker http://rt.cpan.org/Public/ (RT#123456)
Debian http://bugs.debian.org/ (deb#123456)
Fate (Feature tracking tool) https://features.opensuse.org/ (fate#123456)
freedesktop.org http://bugs.freedesktop.org/ (fdo#123456)
GCC http://gcc.gnu.org/bugzilla/ (GCC#123456)
GNOME http://bugzilla.gnome.org/ (bgo#123456)
ICCULUS http://bugzilla.icculus.org/ (bio#123456)
Jenkins CI https://issues.jenkins-ci.org (jenk#123456)
KDE http://bugs.kde.org/ (kde#123456)
Kernel or K http://bugzilla.kernel.org/ (bko#123456)
Launchpad (Ubuntu) https://bugs.launchpad.net/ (lp#123456)
Linux Foundation http://developerbugs.linux-foundation.org/ (lf#1234)
MeeGo http://bugs.meego.com (MeeGo#123456)
Mono http://bugzilla.ximian.com/ (Mono#123456)
Mozilla http://bugzilla.mozilla.org/ (bmo#123456)
Novell https://bugzilla.novell.com/ (bnc#123456)
OpenLDAP http://www.openldap.org/its/ (ITS#123456)
OpenOffice.org (Issuezilla) http://qa.openoffice.org/issues/ (i#123456)
OpenOffice.org Novell (obsolete) https://bugzilla.novell.com/ (n#123456)
openSUSE-Education http://devzilla.novell.com/education/ (os-edu#123456)
RedHat https://bugzilla.redhat.com/ (rh#123456)
Samba https://bugzilla.samba.org/ (bso#123456)
Sourceforge http://sf.net/support/tracker.php?aid=1234567 (sf#1234567); number is in the "aid=" part in an URL
SourceWare http://sourceware.org/bugzilla/ (swo#1234567)
WebKit https://bugs.webkit.org/ (webkit#123456)
Ximian http://bugzilla.ximian.com/ (Ximian#4321)
XFCE https://bugzilla.xfce.org/ (bxo#123456)

Για άλλους αριθμούς bugzilla, παρακαλώ χρησιμοποιήστε την πλήρη διεύθυνση URL για το αντίστοιχο bugzilla στην αρχή του αρχείου patch. Για παράδειγμα:

Σελιδοδείκτης συντομεύσεων

Ένας σελιδοδείκτης για αναζήτηση στο bugzilla.novell.com με προθέματα bnc# μπορεί να βρεθεί εδώ.