Berni341 könnte die .deb/.rpm-Pakete oder evtl. sogar nur deren Verlinkungen direkt vom Software-Anbieter übernehmen, wenn es eine voll funktionsfähige Software wie z.B. debtap dafür gibt.
Das wird aber - wie weiter oben schon angeführt - bei Binärpaketen(z.B. für Debian stable) scheitern, sobald die "Software" dynamisch gelinkt ist. Andere Distributionen (ggf. deren Releases) verwenden z.B. eine ältere/andere Version der libc.so oder libreadline.so. Dann "läuft" die Software nicht. Archlinux ist z.B. per natura näher an Debian sid dran als an stable. Da ändert auch ein aufgemotztes debtap nichts dran.
"Umbaubar" währen am ehesten die jeweilgen Sourcecode-deb/rpm-Pakete, also "wie wird für Debian ein Paket erstellt" umgemodelt zu "wie sieht das PKGBUILD aus". Aber glaub mir, ein neues PKGBUILD zu schreiben ist da deutlich einfacher...
Etwas anderes sind die statisch(bzw. nicht dynamisch) erstellten Pakete, z.B. eben für brave-bin.
Da ist die "Bauanleitung" aus dem AUR doch sehr einfach - verantwortungsvoll! - lokal zu benutzen.
Numm z.B. den letzten Commit aus dem AUR dazu:
https://aur.archlinux.org/cgit/aur.git/commit/?h=brave-bin&id=2dd1ac6b8153ed3419af4cc5d96ce86066278819
Mit ein bißchen "Übung" in PKGBUILDs kann ich hier alles nachvollziehen - und nachprüfen.
- Ist die Upstream-Quelle noch die gleiche? Ist diese neue Version authentisch zu/von Upstream?
- Checksummen (sofern Upstream welche anbietet)
- Sonstige "Änderungen" die nicht in das PKGBUILD gehören?
Nach solch einer Prüfung kann ich doch guten Gewissens diese Änderung in mein lokales PKGBUILD einfließen lassen oder per "Helper" es ggf. auch automatisch erstellen/aktualisieren lassen. Aber ich muß halt mein Gehirn benutzen...