debmake best practice

[mehmetkaprog]

Hi,

ich habe ein Audioconverter-Programm, das .m4a-Audiofiles in .wav-Audiofiles konvertiert.

Es ist ein Python-Programm und ich nutze das um Audio-Dateien aus meinem iPhone umzuwandeln.

Ich schaue mir zurzeit die debmake-Webseite an (https://www.debian.org/doc/manuals/debm ... pa.en.html), um herauszufinden, wie ich dieses Programm in den Debian-Repositories anbieten kann.

Gibt es ein "best practice", welche Schritte ich beim Testen gehen kann, um anschließend mein Programm den Debian-Developern anzubieten?

Mit Testen meine ich jetzt in Virtualbox oder Qemu VMs mit verschiedenen Debian-Versionen aufsetzen und dort ausprobieren und den Audioconverter zum Laufen bringen.

Falls ihr mir da ein bisschen helfen könntet, wäre super. Ich möchte gerne den Prozess verstehen, wie Programme angeboten und in den Repos eingepflegt werden .

Beste Grüße,
mehmetkay-sudo

[heisenberg]

Grundsätzliche Frage: Ergibt es Sinn, Dein Programm aufzunehmen?

Die erste Frage, ob ein neues Programm ins Debian Repository aufgenommen wird, ist: Ergibt es Sinn, dass zu tun? Das würde sich aufteilen in folgende Unterfragen:

1. Bietet das Programm einen relevanten Nutzen für die Allgemeinheit?
2. Bietet das Programm etwas, was noch nicht durch andere Programme abgedeckt ist? Oder wenn andere Programme für den gleichen Zweck existieren: Bietet dieses Programm besondere Merkmale an, die einen zusätzlichen Wert hat?
3. Ist das Programm unter einer freien Lizenz?
4. Ist die Code-Qualität des Programmes ausreichend gut?
5. Ist die Projektqualität ausreichend ((Quellcode-)dokumentation, Qualität des Debianpaketes)

bzgl. a) Nutzen

Ich würde den Nutzen des Programmes von Dir als nicht sonderlich hoch einschätzen. Ein Sounddatei von m4a nach wav zu konvertieren scheint mir mit den vorhandenen, verfügbaren Programmen eine Kleinigkeit. Aber bisher ist das nur eine Einschätzung von mir. Vielleicht täusche ich mich. Du hast ja bisher noch kaum Details zu Deinem Programm genannt. Vielleicht kannst Du Dein Programm etwas genauer beschreiben?

bzgl. b) Funktionalität nicht schon durch andere Programme abgedeckt?

Zum Thema CLI-Soundkonverter fällt mir da direkt mal sox, mplayer, mpv und vielleicht noch ffmpeg ein. Das sind alles große, gut funktionierende Open Source Projekte, die diese Teilfunktionalität bereits anbieten. Da sehe ich keinen Bedarf für ein weiteres Programm.

Damit erübrigt sich dann c, d und e schon.

Du kannst natürlich Dein Paket immer noch über ein eigenes Repository anbieten. Für mich sieht das allerdings eher aus wie ein einfaches Script, dass man vielleicht auf github / codeberg hochladen kann.

[mehmetkaprog]

Hi heisenberg,

danke für deine ausführliche Antwort.

Für zukünftige Ideen für Programme werde ich die Denkanstöße berücksichtigen.

Ich habe in den Dimensionen a-e nicht gedacht. Das stimmt, das Python-Skript, dass ich habe, ist nichts besonderes. Ich denke auch das z.B. eine gute Anlaufstelle ist.

In meinem Programm kann der User über eine tkinter-Fenster eine .m4a-Datei auswählen und diese direkt in .wav umwandeln. Es ist ein kleines Tool.

ffmpeg bietet soweit ich weiß keine gui an, ist jedoch ein äußerst mächtiger Converter.

Besten Dank für deine Antwort!

Grüße,
mehmetkay-sudo