Ich sehe nicht warum beim Bauen eines Paketes dynamisch die Datei debian/control überschrieben werden sollte.
z.B. die Versionsnummer, Author-EMail, Programm-/Paketname, ... Das sind alles Informationen, die in Python-scripten bereits vorhanden sind (module.main.NAME, *.LICENCE, etc) Auch in der setup.py sind diese Infos vorhanden. Redundanzvermeidung ist ein Grundprinzip der Informatik und muss ich an dieser Stelle auch sicher nicht erklären. Redundanz ist ein no-go. Und besonders an dieser Stelle sehe ich keine vernünftige Indikation für diese Redundanz. Es erscheint mir mehr als Design-Problem.
du arbeitest konsequent an den Vorschlägen und den bestehenden Hilfsskripten vorbei und erwartest Funktionalität, die nicht mal dokumentiert
Ja, das sehe ich absolut auch so - da widerspreche ich dir nicht. "bestehende Hilfsskripte": Das ist für mich bisher nie wirklich definiert worden. Welche gibt es, wie stehen diese im Zuammenhang miteinander, wer ruft wen auf, was ist alt, was ist neu, was ersetzt den anderen, was ist für welchen Zweck. Das Große Ganze fehlt mir hier mal wieder. Ich bekomme immer nur Links zu manpage-artigen Dokus der einzelnen Tools oder zu Tutorials, die für Einsatzszenarien gedacht sind, die meinem zu fern sind.
Sicher ist mein Anspruch (keine Redundanz, mehr Automation, mehr Kontrolle, Usability [geht auch ohne GUI!]) auch etwas anders, als das was die Scripte und Tools da so implementieren.
Wie gesagt die Einträge in debian/control sind Sache des Paketmaintainers, das ist IMHO nichts was vom Quelltext ungefragt übernommen werden sollte.
siehe mein Kommentar zur Redundanz. Bei Python ist jede notwendige Information (sogar die Paketabhängigkeiten!) im Code. Der Logik nach brauche ich gar keine controll. Das könnte sich ein Tool mal schön selbst ausm Code rausziehen.
eine neue Version angepasst werden muss das changelog.
Is mir auch noch nicht klar, was ein changlog mit der Paketerstellung zu tun hat. Ich trage dort halt ein, was sich zwischen den Versionen so ändert, damit die User das überblicken können und die Notwendigkeit eines Updates einschätzen können. Was hat der deb-Prozess damit zu tun?
Und was spricht dagegen dann dein Source-Verzeichnis und die setup.py entsprechend zu gestalten oder --install-dir für pybuild entsprechend zu setzen?
Nichts, aber die Information ist mir neu. Woher soll ich die Option --install-dir kennen? Soll ich 100 manpages der beteiligten Tools durchlesen und auch gleich merken? Woher soll ich wissen, das in der manpage von pybuild diese Option erklärt ist bzw. dass pybuild für diesen Schritt der Paketerzeugung verantwortlich ist und nicht ein anderes Script? Soll ich bei der nächsten kleinen Frage, wieder alle 100 manpages durchlesen - den merken tut man sich das ja nicht? Sicher hat pybuild seine Berechtigung - bei meinem aktuellen minimal-Wissensstand über den Gesamtprozess, verstehe ich die Notwendigkeit von pybuild aber bis heute nicht.
Verstehst du meinen workflow? Frag mich immer, wie andere das machen!?
Es ist notwendig, das Gesamtkonzept zu verstehen. Erst dann kann man die vielen kleinen Helferlein auch verstehen, im Prozess korrekt einordnen und auch entscheiden, ob das jetzt Sinn macht oder nicht. Ich denke es bringt hier nichts, weiter über Details zu quatschen, weil wir dann von Problem zu Problem rennen und ich es aber nicht im Gesamten verstehe.
Wenn du setup.py install von Hand aufrufst, landet das doch so wie es jetzt ist auch nicht in einem eigenen Unterverzeichnis, oder?
Keine Ahnung, ich nutze das Script eigentlich nicht. Hab das nur für die deb-Kiste angelegt.