Πακετάρισμα

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

Το Πακετάροντας Python είναι μια εισαγωγή βήμα προς βήμα στο πώς να κατασκευάσετε πακέτο λογισμικού Python για το openSUSE και άλλους χρησιμοποιώντας το openSUSE Build Service.

Περιεχόμενα

1 Ο γρήγορος και αυτοματοποιημένος τρόπος
2 Κόλπα στο πώς να πακετάρετε αρθρώματα Python χεράτα

Ο γρήγορος και αυτοματοποιημένος τρόπος

Ας υποθέσουμε ότι θέλετε να πακετάρετε το zope.interface και δεν ξέρετε πώς ονομάζεται ακριβώς ή από που να το κατεβάσετε. Πρώτα από όλα, μπορείτε να το αναζητήσετε με το py2pack, το οποίο μπορείτε να βρείτε στο πακέτο python-py2pack και να κατεβάσετε την πηγαία αρχειοθήκη αυτόματα με αυτό αν βρείτε το σωστό άρθρωμα:

$ py2pack search zope.interface

searching for module zope.interface...
found zope.interface-3.6.1

$ py2pack fetch zope.interface

downloading package zope.interface-3.6.1...
from http://pypi.python.org/packages/source/z/zope.interface/zope.interface-3.6.1.tar.gz

Ως επόμενο βήμα μπορεί να θέλετε να δημιουργήσετε μια συνταγή πακέτου για τη διανομή σας. Για βασισμένες στο RPM διανομές, θέλετε να δημιουργήσετε ένα αρχείο spec με την ονομασία python-zopeinterface.spec:

$ py2pack generate zope.interface -f python-zopeinterface.spec

Η πηγαία αρχειοθήκη και η συνταγή για το πακέτο είναι όλα όσα σας χρειάζονται για να δημιουργήσετε το αρχείο RPM. Αυτό το τελευταίο βήμα μπορεί να διαφέρει ανάλογα με τη διανομή την οποία χρησιμοποιείτε. Και πάλι, για το openSUSE (και χρησιμοποιώντας το openSUSE Build Service), η πλήρης διαδικασία είναι η εξής:

$ osc mkpac python-zopeinterface
$ cd python-zopeinterface
$ py2pack fetch zope.interface
$ py2pack generate zope.interface -f python-zopeinterface.spec
$ osc build
$ osc vc
$ osc commit

Η πρώτη γραμμή χρησιμοποιεί το osc, το εργαλείο γραμμής εντολών του Build Service για τη δημιουργία ενός νέου πακέτου (κατά προτίμηση στον προσωπικό σας χώρο έργων στο Build Service). Τα βήματα για το py2pack είναι ήδη γνωστά. Τέλος, το πακέτο ελέγχεται (κατασκευάζεται τοπικά), ένα αρχείο αλλαγών (changelog πακέτου) δημιουργείται (με το ‘osc vc’) και το αποτέλεσμα αποστέλλεται πίσω στο Build Service για δημόσια κατανάλωση. Ωστόσο, ανάλογα με το άρθρωμα της Python, μπορεί να χρειαστεί να προσαρμόσετε ελαφρώς το δημιουργημένο αρχείο. Το py2pack είναι αρκετά έξυπνο και προσπαθεί να δημιουργήσει αυτόματα όσα περισσότερα μπορεί, αλλά εξαρτάται από τα μεταδεδομένα που το ίδιο το άρθρωμα παρέχει. Συνεπώς, κακά μεταδεδομένα implies μέτρια αποτελέσματα. Για περισσότερη βοήθεια πάνω στη χρήση του py2pack, δώστε την ακόλουθη εντολή:

$ py2pack help

Συχνά, η πρώτη εκτέλεση του 'osc build' θα αποτύχει δίνοντας μηνύματα σφάλματος της κατασκευής, λόγω ελλείψεων σε αρθρώματα της python. Ψάξτε για τη λέξη 'import', αυτό θα σας δώσει μια ιδέα, για το τι χρειάζεται να προσθέσετε στο 'BuildRequires:' του αρχείου spec σας.

Αν τα πράγματα αρχίσουν να περιπλέκονται και χρειάζεται να επεξεργαστείτε περισσότερα αρχεία spec, έχετε υπόψη ότι υπάρχουν πολλές έτοιμες μακροεντολές rpm για να σας βοηθήσουν. Π.χ. %{py_libdir}, %{py_sitedir}, %{py_ver} -- δείτε το /usr/lib/rpm/macros.python για περισσότερα.

Κόλπα στο πώς να πακετάρετε αρθρώματα Python χεράτα

Το πακετάρισμα με το χέρι δεν προτείνεται αφού έχουμε εργαλεία που κάνουν τη δουλειά. Αν επιμένετε να διασκεδάσετε με αυτό τον τρόπο, λάβετε υπόψη οποιοδήποτε αρχείο spec στα devel:languages:python3. python-nose, python-pip or python-Sphinx τα οποία αποτελούν καλά παραδείγματα.

Πολιτική ονομασίας

Η SUSE έχει μια πολιτική για την ονομασία των πακέτων αρθρωμάτων της Python. Ένα άρθρωμα είναι για την Python ότι και οι κοινόχρηστες βιβλιοθήκες για τη C - ένα κομμάτι κώδικα που δεν δουλεύει από μόνο του, αλλά παρέχει λειτουργικότητα σε άλλα προγράμματα Python.

Όλα τα πακέτα αρθρωμάτων της Python, είτε γραμμένα σε καθαρή Python είτε βασισμένα στη C, πρέπει να ονομάζονται python-modulename. Το modulename πρέπει να είναι το όνομα του αρθρώματος στον Κατάλογο Πακέτων Python, το επίσημο αποθετήριο λογισμικού τρίτου-προσώπου για τη γλώσσα προγραμματισμού Python.

Προηγουμένως, τα πακέτα Python ονομάζονταν από τους καταλόγους στην ιεραρχία του site-packages. Συχνά, αυτό ήταν μια αυθαίρετη επιλογή, καθώς πολλά αρθρώματα εγκαθιστούν περισσότερους του ενός καταλόγους εκεί. Επίσης, ο κόσμος της Python συμπεριλαμβάνει αρθρώματα που μοιράζονται την ίδια ονομασία καταλόγου (αναζητήστε για "daemon" στο PyPI) και δεν ήταν πάντα εύκολο να βρεθεί πιο ήταν τελικά πακέτο. Επιπλέον, η νέα προσέγγιση έχει διάφορα πλεονεκτήματα:

Σενάρια (όπως το py2pack) ξέρουν από που να φέρουν τα μεταδεδομένα και (νέα) διαθέσιμα tarballs, το PyPI έχει ένα σταθερό API
Οι ονομασίες των πακέτων ταιριάζουν με τα install_required, κλπ στα αρχεία setup.py και στα αρχεία απαιτήσεων pip διευκολύντας την εύρεση των (Build)Requires στα RPM specs
Οι χρήστες ξέρουν που να αναζητήσουν τεκμηρίωση χρήσης του API: http://pypi.python.org/pypi/$PYPYNAME

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

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

BuildRequires

Σε κάθε περίπτωση, χρησιμοποιήστε το BuildRequires: python-devel. Τεχνικά το BuildRequires: python-base είναι αρκετό για αρθρώματα μόνο σε Python (π.χ. καθόλου κώδικας C), αλλά αυξάνει τη συνέπεια και δεν προσθέτει πολλά γενικά.

Κάποια αρθρώματα απαιτούν το setuptools για να κατασκευαστούν. Σε αυτή την περίπτωση προσθέστε το πακέτο BuilRequires: python-setuptools ~~ή κατά προτίμηση το διάδοχό του ως BuildRequires: python-distribute~~2013-10-16: η διανομή είναι ένα παρακλάδι του setuptools και έγινε επειδή η ανάπτυξη παρουσίασε στασιμότητα. Στο μεταξύ, το όλο έργο καταλείφθηκε από διανομείς προγραμματιστές που τελικά αναμείχθηκαν. Σήμερα το setuptools είναι αρκετά δραστήριο πάλι και έθεσε τη διανομή ως ξεπερασμένη (ξανά). -- σημείωσε ο Saschpe.

Λόγω του πώς ο διερμηνέας της Python είναι διαχωρισμένος στα πακέτα "python" και "python-base", μερικές φορές πρέπει να πείτε BuildRequires: python στο αρχείο spec σας. Αυτό ισχύει ειδικότερα αν χρειάζεστε κάποιο από τα ακόλουθα αρθρώματα της Python κατά την κατασκευή\: ssl, _ssl, md5, sha.

Έκδοση Python

Στο openSUSE, ακόμα και πακέτα που δεν ενδιαφέρονται για κάποια συγκεκριμένη έκδοση πρέπει να εξαρτώνται από κάποια συγκεκριμένη σειρά εκδόσεων της python. Μια σειρά εκδόσεων της python καθορίζεται από τον κύριο αριθμό της (major) και από το δευτερεύοντα (minor). Για παράδειγμα, η τωρινή (για τις 3.4.2013) σειρά εκδόσεων της python είναι η 2.7 για την σταθερή γραμμή (legacy) και η 3.3 για την Python 3.
Αυτό συμβαίνει επειδή κάνετε την εγκατάσταση σε κατάλογο ανάλογα με την έκδοση: /usr/lib(64)/pythonX.Y/site-packages, όπου X.Y είναι η σειρά.

Τοποθεσίες αρχείων

Όλα τα πηγαία αρχεία και τα αρχεία bytecode της python θα πρέπει να πάνε στο /usr/lib(64)/pythonX.Y/site-packages, ή ίσως στο /usr/lib(64)/yourapp. Το FHS λέει ότι η ιεραρχία καταλόγων /usr/share θα πρέπει να περιέχει μόνο δεδομένα, οπότε μην εγκαθιστάτε πηγαία εκεί.
Αυτό δεν είναι μια αυστηρή απαίτηση, βέβαια, μόνο προτείνεται. Αν το upstream του πακέτου επιμένει να εγκαθιστά στο /usr/share, προσπαθήστε να τους πείσετε ότι ο τρόπος τους είναι λάθος, αλλά μην αισθανθείτε υποχρεωμένοι να μπαλώσετε το πακέτο μέχρις εσχάτων για να εγκαθίσταται στο /usr/lib.

Λίστες αρχείων

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

%python_sitelib επεκτείνεται στο /usr/lib/pythonX.Y/site-packages. Αυτή είναι η τοποθεσία εγκατάστασης για αρθρώματα ανεξαρτήτου πλατφόρμας.
%python_sitearch επεκτείνεται στο %{_libdir}/pythonX.Y/site-packages, αυτό είναι, είτε το /usr/lib είτε το /usr/lib64, ανάλογα με την αρχιτεκτονική σας. Αυτή είναι η τοποθεσία για αρθρώματα που εξαρτώνται από την πλατφόρμα.

Οπότε, για ανεξαρτήτου πλατφόρμας πακέτα Python, το πιο απλό παράδειγμα θα έδειχνε κάπως έτσι:

%install
python setup.py install --prefix=%{_prefix} --root=%{buildroot}

%files
%defattr(-,root,root)
%{python_sitelib}/*

Για την αποφυγή συγκρούσεων με πακέτα για άλλους διερμηνευτές Python, δυαδικά και/ή σελίδες-τεκμηρίωσης (man-pages) πρέπει να επιθεματίζονται με τις εκδόσεις των διερμηνέων, π.χ.:

%{_bindir}/foo

πρέπει να γίνει

%{_bindir}/foo-%{py_ver}

Ελέγξτε το τμήμα παρακάτω για Python3 / παράλληλη εγκατάσταση.

Αρχιτεκτονική Συστήματος

Αν το πακέτο σας περιέχει μόνο αρχεία πηγαίου κώδικα python (.py), αρχεία bytecode (.pyc και .pyo) και δεδομένα ανεξάρτητα πλατφόρμας, θα πρέπει να το σημειώσετε ως noarch. Συμπεριλάβετε το BuildArchitectures: noarch στην αρχή του spec σας. Τέτοια αρθρώματα θα πρέπει να εγκαθίστανται εξολοκλήρου στο %python_sitelib.

Διαφορετικά, ολόκληρο το άρθρωμα εγκαθίσταται στο %python_sitearch. Σημειώστε ότι δεν είναι δυνατόν να έχετε ένα τμήμα ενός αρθρώματος στο %python_sitelib και ένα άλλο στο %python_sitearch. Και στις περισσότερες περιπτώσεις, ακόμα κι αν ένα πακέτο περιέχει περισσότερα από ένα αρθρώματα, όλα θα πρέπει να βρίσκονται στο ίδιο πρόθεμα.

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

Ορισμένα πακέτα μπορεί να εγκαταστήσουν τμήματα του εαυτού τους στο %python_sitelib και τμήματα στο %python_sitearch. Τέτοια στησίματα είναι μια κλασσική πηγή σφαλμάτων (bug) και προβλημάτων. Εκτός κι αν ξέρετε ακριβώς τι κάνετε, θα πρέπει να τροποποιήσετε τέτοια πακέτα ώστε όλα να πηγαίνουν στο %python_sitearch.

setuptools/eggs

Προσοχή Αυτό το κείμενο εισήχθηκε από τις οδηγίες για το Fedora και δεν έχει αναθεωρηθεί για το openSUSE ακόμα. Χρησιμοποιήστε το με δική σας ευθύνη.

Στο παρελθόν, το Fedora έχει κάνει τα λιγότερα δυνατά για την υποστήριξη των eggs για τις upstream διανομές. Καθώς τα eggs υιοθετούνται όλο και πιο ευρέως στο upstream χρειαζόμαστε πιο περιεκτική τεκμηρίωση στο πως να το χειριστούμε αυτό το θέμα. Τα ακόλουθα είναι μια περίληψη των κατευθυντήριων γραμμών για αναθεωρητές ώστε να συνεχίσουν από εκεί. Η ολοκληρωμένη πολιτική συμπεριλαμβάνει παραδείγματα και τη λογική με την οποία εμείς κάνουμε τα πράγματα.

Πρέπει: Τα Python eggs πρέπει να κατασκευαστούν από πηγαίο κώδικα. Δεν μπορεί να μπει ένα egg από το upstream κατευθείαν στον κατάλληλο κατάλογο.
Πρέπει: Τα Python eggs δεν πρέπει να κατεβάζουν εξαρτήσεις κατά τη διαδικασία της κατασκευής.
Πρέπει: Αν τα αρχεία egg-info δημιουργούνται από τα σενάρια κατασκευής αρθρωμάτων τότε πρέπει και αυτά να συμπεριληφθούν στο πακέτο.
Πρέπει: Κατά την κατασκευή ενός συμβατού πακέτου, πρέπει να εγκαθίσταται με το easy_install -m ώστε να μην συγκρούεται με το κύριο πακέτο.
Πρέπει: Κατά την κατασκευή πολλαπλών εκδόσεων (για ένα συμβατό πακέτο) ένα από τα πακέτα πρέπει να συμπεριλαμβάνει μια προεπιλεγμένη έκδοση που να μπορεί να χρησιμοποιηθεί μέσω του "import MODULE" χωρίς προηγούμενο στήσιμο.
Θα έπρεπε: Ένα πακέτο που χρησιμοποιείται από κάποιο άλλο πακέτο μέσω μιας διεπαφής egg θα έπρεπε να παρέχει πληροφορίες για το egg.

Μεταγλωττισμένα Αρχεία σε μορφή Byte

Η Python αυτόματα προσπαθεί να μεταγλωττίσει αρχεία σε κάθε εκτέλεση ώστε να επιταχύνει την εκκίνηση κατά την επόμενη εκτέλεση της εφαρμογής. Αυτά τα αρχεία αποθηκεύονται με την κατάληξη .pyc (μεταγλωτισμένη python) ή .pyo (βελτιστοποιημένη μεταγλωττισμένη python). Αυτά τα αρχεία είναι ένα είδος μεταφέρσιμου κώδικα μεταξύ λειτουργικών συστημάτων. Αν δεν τα συμπεριλάβετε στο πακέτο σας, η python θα προσπαθήσει να τα δημιουργήσει κατά την εκτέλεση του προγράμματος. Αν ο διαχειριστής του συστήματος τα χρησιμοποιήσει, τότε τα αρχεία θα δημιουργηθούν επιτυχώς. Αργότερα, όταν το πακέτο αφαιρεθεί, τα αρχεία .pyc και .pyo θα παραμείνουν στο σύστημα αρχείων. Για να το αποτρέψετε αυτό πρέπει να μεταγλωττίσετε τα αρχεία κατά την κατασκευή του πακέτου και να τα συμπεριλάβετε στον τομέα %files.

Πολλά πακέτα εγκαθιστούν μεταγλωττισμένα .pycs και .pyos από μόνα τους. Αν το πακέτο σας δεν το κάνει, θα πρέπει να χρησιμοποιήσετε το %{py_compile} <κατάλογος> για να δημιουργήσετε τα .pyc και το %{py_compile -O} <κατάλογος> για τα .pyo αρχεία.

Τις περισσότερες φορές, τα αρχεία .pyo είναι ακριβώς τα ίδια με τα .pyc. Μπορείτε να γλυτώσετε χώρο εκτελώντας το fdupes για να δημιουργήσετε hardlink μεταξύ τους.

BuildRequires: fdupes
(...)

%install
(...)
%fdupes $RPM_BUILD_ROOT%{py_sitedir}

Περίληψη χρήσιμων μακροεντολών rpm

%py_ver - σειρά εκδόσεων python (πρωτεύων.δευτερεύων αριθμός έκδοσης)
%py_compile - μεταγλωττίζει σε μορφή byte πηγαία αρχεία python από τον ορισμένο κατάλογο. Χρησιμοποιήστε %{py_compile -O} για να παράγετε βελτιστοποιημένο bytecode (.pyo)
%py_requires - ορίζει ένα BuildRequires για τον διερμηνευτή της python και ένα Requires (για την ακρίβεια PreReq) για συγκεκριμένη σειρά εκδόσεων της python. Χρησιμοποιήστε %py_requires -d για να συμπεριλάβετε επίσης στις εξαρτήσεις και το python-devel
%python_sitelib - ο κατάλογος site-packages για αρθρώματα ανεξάρτητα πλατφόρμας. Επεκτείνεται σε /usr/lib/python%{py_ver}/site-packages
%python_sitearch - ο κατάλογος site-packages για αρθρώματα συγκεκριμένης πλατφόρμας. Επεκτείνεται σε %{_libdir}/python%{py_ver}/site-packages

Συμβατότητα με παλαιότερες διανομές

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

Η δυνατότητα κατασκευής πακέτων noarch, μαζί με τα %python_sitelib και %python_sitearch, πρωτοεισήχθη στην 11.2. Αν χρειάζεστε συμβατότητα με παλαιότερες διανομές, πρέπει να ορίσετε τις μακροεντολές που χρησιμοποιείτε. Τοποθετήστε αυτό στην αρχή του spec σας:

%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")}
%{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")}

Αν το πακέτο σας είναι noarch, πρέπει να βάλετε τη δήλωση noarch μέσα σε μια ακολουθία υπόθεσης (conditional sequence).

Αυτό θα κατασκευάσει το πακέτο σας ως noarch μόνο για το openSUSE 11.2 και για νεώτερες εκδόσεις:

%if 0%{?suse_version} >= 1120
BuildArchitectures: noarch
%endif

Και αυτό θα κατασκευάσει το πακέτο σας ως noarch για το openSUSE 11.2 και νεώτερες εκδόσεις, συν για κάθε άλλη μη-SUSE διανομή. (Χρήσιμο όταν κατασκευάζετε πακέτα για το Fedora)

%if %{?suse_version: %{suse_version} > 1110} %{!?suse_version:1}
BuildArchitectures: noarch
%endif

Κόλπα για το πώς να Πακετάρετε αρθρώματα Python3

Ιστορικά, η Python-2.7 ήταν η προεπιλεγμένη έκδοση διερμηνέα. Από την έκδοση openSUSE-13.1 θα είναι η Python-3.3. Πακέτα για Python-2.x αναπτύσσονται στο έργο OBS devel:languages:python, ενώ τα πακέτα Python-3.x αναπτύσσονται στο devel:languages:python3.

Προτείνεται να κατασκευάσετε πακέτα και για τις δύο εκδόσεις. Ορίστε και μια μικρή διαδικασία για το πώς να το κάνετε:

Ξεκινήστε το πακετάρισμα του python-$FOO με το py2pack.
Υποβάλετέ το στο devel:languages:python. Περιμένετε μέχρι να γίνει αποδεκτό. Αν όχι διορθώστε τα προβλήματα που απομένουν.
Δημιουργήστε ένα ξεχωριστό πακέτο python3-$FOO αντιγράφοντας το python-$FOO με το osc copypac.
Μετονομάστε όλα τα αρχεία από python-* σε python3-* .
Ανοίξτε το αρχείο python3-$FOO.spec και:
1. Αντικαταστήστε κάθε εξάρτηση με την αντίστοιχη της python3.
2. Αλλάξτε το %py_ver σε %py3_ver.
3. Αλλάξτε το %python_sitelib σε %python3_sitelib.
Αφαιρέστε τις όποιες μακροεντολές συμβατότητας για εκδόσεις του openSUSE παλαιότερες της 12.2.
Κάνετε Build το πακέτο τοπικά.
Υποβάλετε το πακέτο σας στο devel:languages:python3.

Για να ακολουθήσετε κατά γράμμα το παραπάνω παράδειγμα, λάβετε υπόψη το python3-Sphinx.

Παράλληλη εγκατάσταση

Για να μπορεί να εγκατασταθεί παράλληλα και η Python-2.x και η Python-3.x έκδοση ενός πακέτου, πρέπει να αποφευχθούν συγκρούσεις αρχείων. Γενικά, αυτό συμπεριλαμβάνει τη μη εγκατάσταση όλων των αρχείων στο %{python_sitelib} / %{python_sitearch} (και τα αντίστοιχά τους σε Py3k) ούτε το μαρκάρισμά αρχείων ως %doc. Με άλλα λόγια, δείτε το ακόλουθο τμήμα %files:

%{_bindir}/foo
%{_mandir}/man1/foo.1.gz

Εικονίδια, αρχεία *.desktop και δεδομένα εφαρμογών στο %{_datadir} μπορούν επίσης να συγκρούονται. Η σωστή λύση είναι η χρήση του update-alternatives. Τα υπάρχοντα πακέτα που αναφέρθηκαν υλοποιούν όλα με το σωστό τρόπο το update-alternatives, οπότε συμβουλευτείτε το.

Δείτε το openSUSE:Python 3 Status για μια λίστα κατάστασης πακέτων Python και των αντίστοιχών τους σε Python3 στο openSUSE.

openSUSE:Packaging Python