TLP – Entwicklerthread

blafoo

blafoo

Moderator
Themenstarter
Registriert
11 März 2011
Beiträge
7.998
Hi,

um die Entwicklungsthemen vom Support abzugrenzen mach ich mal einen eigenen Thread auf.

Ziel dieses Threads ist die Diskussion von Themen die Weiterentwicklung und Paketierung von TLP betreffen. Lesestoff: TLP Entwickler-Dokumentation

Supportanfragen sowie "Smalltalk" sind in diesem Thread "Off Topic" und somit unerwünscht.

Supportfragen also bitte hier posten -> klickmich. Danke für euer Verständnis.

Grüße Linnrunner

(Durch aufräumarbeiten ist der Thread nun in mein Eigentum übergegangen ^^)
 
Zuletzt bearbeitet:
Bim immer noch neugierig wie das apci_call-git funktioniert: vom PKGBUILD würde ich mir zusammenreinen, dass einmalig der neueste Stand aus dem Git-Repo gezogen wird (git pull origin). Aber wie macht es Updates – das Package hochversionieren?
 
Wie bei den meisten AUR-Paketen, die ihren Source aus einem Repo ziehen, wird bei jedem Update die aktuellste Version installiert. Es gibt also keine Versionsnummer. Üblicherweise wird dann der gekürzte SHA1-Hash als Version genutzt. Alternativ kann man das PKGBUILD auch so schreiben, dass ein bestimmter Tag geladen wird (z.B. eine bestimmte Version) - dann müsste auch das PKGBUILD jedes Mal angepasst werden.

Kurz: Wenn man das Paket aktualisiert (manuell oder mit einem der vielen Helper), dann wird immer die aktuellste Version installiert (und eine Versionsnummer gibt es in diesem Fall nicht).
 
Aber damit die Helper/Tools überhaupt erkennen können, dass es etwas zu aktualisieren gibt, macht man doch eine höhere Paketversion?!
 
https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines

Man kann die Versionsnummer dynamisch erzeugen. Wenn man das AUR-Paket updaten möchte, wird die Funktion ausgeführt, wodurch geprüft werden kann, ob es eine aktuellere Version gibt. in dem PGKBUILD von acpi_call-git ist das aber nicht implementiert.

edit: Oder wie unter mir. Hängt immer davon ab, wie man die Pakete verwaltet und installiert.
 
Helper, wie Packer / Yaourt, gehen einfach her und installieren GIT-Pakete einfach IMMER neu.

Egal wie die Releasenummer ist.

Bei anderen Paketen, wie das TLP-Paket zb, muss ich immer die Nummer händisch setzten, wenn ich halt will das die Leute mit ihren Helpern das Update bekommen. Sonst bekämen es nur die neu installierenden :)

Grüße
 
Zuletzt bearbeitet:
@blafoo: WOL Ausschalten für alle Ethernet Devices, unabhängig vom Namen, ist jetzt im devel-Branch verfügbar. Bitte testen ... :)
 
Zuletzt bearbeitet:
Nö :P

Schau ich mir morgen/übermorgen mit dem post_install an ;)

Grüße
 
@blafoo: immer mit der Ruhe. Ich wollte es doch nur kundtun :).
 
Zwei Anmerkungen zu den PPA-Paketen:

1. Aus der FAQ [1]:
Important: TLP explicitly refuses to run when laptop-mode-tools is installed.
Zum Vergrößern anklicken....
Gibt es einen Grund, warum laptop-mode-tools dann nicht als "Conflicts" im config des Ubuntupakets steht?:
Code: 
Package: tlp
Version: 0.5-1~trusty
Architecture: all
Maintainer: Thomas Koch <linrunner@gmx.net>
Installed-Size: 247
Depends: pm-utils
Recommends: tlp-rdw, acpid, ethtool, smartmontools, wireless-tools
Suggests: acpi-call, tp-smapi-dkms
Conflicts: pm-utils-powersave-policy
Section: utils
Priority: optional
Homepage: http://linrunner.de/tlp
Description: Save battery power on laptops
 TLP implements advanced power management for Linux. TLP is a pure
 command line tool with automated background tasks. It does not
 contain a GUI.


2. postinst/postrm sieht mir unsauber aus.
postinst:
Code: 
# Disable conflicting pm-utils hooks
        for i in 95hdparm-apm disable_wol hal-cd-polling intel-audio-powersave harddrive \
                 laptop-mode journal-commit pci_devices pcie_aspm readahead sata_alpm \
                 sched-powersave usb_bluetooth wireless xfs_buffer; do
            if [ -x /usr/lib/pm-utils/power.d/$i ]; then
                ln -sf /usr/lib/tlp-pm/tlp-nop /etc/pm/power.d/$i
            fi
        done
postrm:
Code: 
# Remove pm-utils hook disablers
        for i in 95hdparm-apm disable_wol hal-cd-polling intel-audio-powersave harddrive \
            laptop-mode journal-commit pci_devices pcie_aspm readahead sata_alpm \
            sched-powersave usb_bluetooth wireless xfs_buffer; do
            if [ "$(readlink /etc/pm/power.d/$i)" = "/usr/lib/tlp-pm/tlp-nop" ]; then
                rm /etc/pm/power.d/$i
            fi
        done
Du löschst bei der Installation eine Reihe von Dateien, stellst sie aber nach der Deinstallation nicht wieder her.


[1] http://linrunner.de/en/tlp/docs/tlp-faq.html
 
hikaru schrieb:
Gibt es einen Grund, warum laptop-mode-tools dann nicht als "Conflicts" im config des Ubuntupakets steht?
Zum Vergrößern anklicken....
Ja, einen historischen: damals wusste ich es nicht besser, heute würde ich ein "conflicts l-m-t" aufnehmen. Ein nachträglich aufgenommenes conflicts würde jedoch die TLP-Updates blockieren, daher bleibt es bis auf weiteres wie es ist.

hikaru schrieb:
Du löschst bei der Installation eine Reihe von Dateien, stellst sie aber nach der Deinstallation nicht wieder her.
Zum Vergrößern anklicken....
Umgekehrt wird ein Schuh daraus: nach der Installation setzt postinst Symlinks, die nach dem Entfernen des Pakets postrm wieder abräumt. Deutlich zu sehen in deinem Post.
 
linrunner schrieb:
Ja, einen historischen: damals wusste ich es nicht besser, heute würde ich ein "conflicts l-m-t" aufnehmen. Ein nachträglich aufgenommenes conflicts würde jedoch die TLP-Updates blockieren, daher bleibt es bis auf weiteres wie es ist.
Zum Vergrößern anklicken....
Wieso sollte es die blockieren? Wer aktuell schon tlp verwendet hat doch deiner FAQ entsprechend laptop-mode-tools händisch deinstalliert.

linrunner schrieb:
Umgekehrt wird ein Schuh daraus: nach der Installation setzt postinst Symlinks, die nach dem Entfernen des Pakets postrm wieder abräumt. Deutlich zu sehen in deinem Post.
Zum Vergrößern anklicken....
Du setzt Links mit ln -sf. Dabei überschreibst du die vormals in /etc/pm/power.d/ befindlichen Dateien und kannst sie bei der Deinstallation nicht zurückholen.
 
linrunner schrieb:
Möglicherweise.
Zum Vergrößern anklicken....
Mit der Herangehensweise wirst du auf ewig Pakete mit kaputten Abhängigkeiten ausliefern. Das ist natürlich deine Entscheidung, aber der aktuelle Zustand von tlp bestärkt mich erneut in der Herangehensweise nicht jedes Drittanbieterpaket zu installieren das nicht bei drei auf den Bäumen ist.

linrunner schrieb:
Aber der User hat sie ja (hoffentlich) schon vor der Installation entfernt, siehe Anleitung ;).
Zum Vergrößern anklicken....
Nein, hat er nicht. Dort stehen Dateien aus pm-utils [1]. Das steht nicht im Konflikt mit tlp, sondern tlp hängt sogar davon ab. Wenn ein User nun eine gewöhnliche Ubuntuinstallation durchführt, dann hat er erstmal nur pm-utils installiert. Dann stolpert er über tlp, will es mal ausprobieren, installiert es, stellt aber irgendwann fest, dass er es eigentlich nicht braucht. Also deinstalliert er es wieder und steht nun mit einem kaputten pm-utils da.
Irgendwo in den Debian-Paketrichtlinien steht, dass keine zwei gleichzeitig installierbaren Pakete die gleichen Dateien ausliefern dürfen, um genau so eine Situation zu vermeiden. Mir erscheint der Stellenwert von tlp als zu groß um das einfach zu ignorieren. Meiner Meinung nach solltest du als Maintainer eines so bedeutenden PPAs den Anspruch haben saubere Pakete auszuliefern.


[1] http://packages.ubuntu.com/trusty/all/pm-utils/filelist
 
Ist das nicht eher was für den Entwicklerthread?
hikaru schrieb:
Mit der Herangehensweise wirst du auf ewig Pakete mit kaputten Abhängigkeiten ausliefern. Das ist natürlich deine Entscheidung, aber der aktuelle Zustand von tlp bestärkt mich erneut in der Herangehensweise nicht jedes Drittanbieterpaket zu installieren das nicht bei drei auf den Bäumen ist.
Zum Vergrößern anklicken....

Sofern man TLP_ENABLE=0 setzt, kann man TLP installiert haben und dennoch l-m-t nutzen. Warum diese Möglichkeit ausschließen?


Nein, hat er nicht. Dort stehen Dateien aus pm-utils [1]. Das steht nicht im Konflikt mit tlp, sondern tlp hängt sogar davon ab. Wenn ein User nun eine gewöhnliche Ubuntuinstallation durchführt, dann hat er erstmal nur pm-utils installiert. Dann stolpert er über tlp, will es mal ausprobieren, installiert es, stellt aber irgendwann fest, dass er es eigentlich nicht braucht. Also deinstalliert er es wieder und steht nun mit einem kaputten pm-utils da.
Zum Vergrößern anklicken....

Das einzige, was verloren geht, sind die selbst erstellten Hooks in /etc/pm/power.d, die man idR anders benennt.

Im übrigen werde ich in künftigen Versionen statt der Symlinks folgenden Schnipsel ausliefern und nach /etc/pm/config.d/tlp installieren:

Code: 
# don't leak TLP vars
if (
   CONFFILE=/etc/tlp.conf ## /etc/default/tlp
   [ -f "${CONFFILE}" ] && . "${CONFFILE}" -- && [ "${TLP_ENABLE}" = "1" ]
) 1>/dev/null 2>&1; then
HOOK_BLACKLIST="
95hdparm-apm
disable_wol
hal-cd-polling
harddrive
intel-audio-powersave
journal-commit
laptop-mode
pci_devices
pcie_aspm
readahead
sata_alpm
sched-powersave
usb_bluetooth
wireless
xfs_buffer
"
fi


vg,
dywi
 
dywi schrieb:
Ist das nicht eher was für den Entwicklerthread?
Zum Vergrößern anklicken....
Vermutlich. Vielleicht kann ein Mod die entsprechenden Beiträge verschieben.

dywi schrieb:
Sofern man TLP_ENABLE=0 setzt, kann man TLP installiert haben und dennoch l-m-t nutzen. Warum diese Möglichkeit ausschließen?
Zum Vergrößern anklicken....
In dem Fall müsste der FAQ-Text berichtigt werden und tlp sich darum kümmern laptop-mode-tools zu deaktivieren falls TLP_ENABLE=1 ist.

dywi schrieb:
Das einzige, was verloren geht, sind die selbst erstellten Hooks in /etc/pm/power.d, die man idR anders benennt.
Zum Vergrößern anklicken....
Und außerhalb der (welcher?) Regel?
Es mag ja unwahrscheinlich sein, dass da was überschrieben wird, aber offenbar ist euch der Umstand an sich bewusst, sonst würdet ihr die Hooks nicht per postinst überschreiben. Was spräche denn dagegen, die existiernden Hooks zu verschieben und beim postrm wieder zurückzuholen?

dywi schrieb:
Im übrigen werde ich in künftigen Versionen statt der Symlinks folgenden Schnipsel ausliefern und nach /etc/pm/config.d/tlp installieren:

Code: 
# don't leak TLP vars
if (
   CONFFILE=/etc/tlp.conf ## /etc/default/tlp
   [ -f "${CONFFILE}" ] && . "${CONFFILE}" -- && [ "${TLP_ENABLE}" = "1" ]
) 1>/dev/null 2>&1; then
HOOK_BLACKLIST="
95hdparm-apm
disable_wol
hal-cd-polling
harddrive
intel-audio-powersave
journal-commit
laptop-mode
pci_devices
pcie_aspm
readahead
sata_alpm
sched-powersave
usb_bluetooth
wireless
xfs_buffer
"
fi
Zum Vergrößern anklicken....
Ohne das jetzt vollkommen zu überblicken scheint mir das die bessere Alternative.
 
hikaru schrieb:
In dem Fall müsste der FAQ-Text berichtigt werden und tlp sich darum kümmern laptop-mode-tools zu deaktivieren falls TLP_ENABLE=1 ist.
Zum Vergrößern anklicken....

bzgl. FAQ: Nein, eine parallele Installation von tlp und l-m-t wird nicht unterstützt. Sie ist möglich, da man TLP deaktivieren kann, das war's aber auch schon.

bzgl. l-m-t deaktivieren: Wie soll das ablaufen? "l-m-t, du hast die Hardware jetzt lange genug gehabt"? (vgl. auch konkurriende Netzwerkdienste, ...)

Und außerhalb der (welcher?) Regel?
Zum Vergrößern anklicken....
Praktisch ist man eher am Hinzufügen eigener Skripte interessiert, als die Systemskripte zu überschreiben. Natürlich gibt es auch Ausnahmen.

Es mag ja unwahrscheinlich sein, dass da was überschrieben wird, aber offenbar ist euch der Umstand an sich bewusst, sonst würdet ihr die Hooks nicht per postinst überschreiben.
Was spräche denn dagegen, die existiernden Hooks zu verschieben und beim postrm wieder zurückzuholen?
Zum Vergrößern anklicken....
Dass das mit den Links ein bisschen "hacky" ist, steht außer Frage. Aber es funktioniert, ist wenig komplex und bereits implementiert. Gegen verschieben/zurückholen spricht vor allem mangelndes Interesse (zumindest meinerseits). Außerdem gibt es beim Zurückholen ggf. das ein oder andere zu beachten.

Wenn du da Handlungsbedarf siehst, kannst du einen Patch einsenden.

Ohne das jetzt vollkommen zu überblicken scheint mir das die bessere Alternative.
Zum Vergrößern anklicken....
Der "Nachteil" daran ist: (a) ungetestet (b) bei manchen Distributionen werden die Hooks als "success" statt "blacklisted" geloggt (der Bug ist upstream bekannt _1 _2, aber wohl nicht wichtig)
 
@hikaru: ich will das Package ohnehin überarbeiten, bei der Gelegenheit werde ich deine Hinweise berücksichtigen. Danke dafür.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben