# [gelöst] k3b mit/ohne hal

## Christian99

Hallo, heute gabs mal wieder ein neues k3b, laut website: "Added K3B_ENABLE_HAL_SUPPORT option to the build configuration. It allows to disable any direct calls to HAL"

Schon gefreut, k3b war bisher das letzte paket, das hal benötigt hat.

Nach der installation die enttäuschung, immer noch keine optischen laufwerke gefunden von k3b. Hal war schon von system verschwunden, und lässt sich jetzt nicht mehr installieren, sonst hätt ich den dienst gestartet, so hats vorher funktioniert.

Daraufhin hab ich mir mal das ebuild von k3b angeschaut, und gesehen dass K3B_ENABLE_HAL_SUPPORT nicht explizit gesetzt wird, und ich hab auf die schnelle nicht gefunden, was default ist, also hab ich das ebuild modifiziert, so das K3B_ENABLE_HAL_SUPPORT=off explizit gesetzt wird. hat aber nach dem neubauen keine änderung gebracht.

Was muss ich denn sonst noch machen, dass k3b funktioniert? braucht man trotzdem noch hal? wieso ist es dann aus den dependencies verschwunden?

Danke für die Hilfe

ChristianLast edited by Christian99 on Sat Jan 29, 2011 12:08 pm; edited 1 time in total

----------

## ScytheMan

ich schätze du brauchst noch sys-fs/udisks

bei mir unter kde 4.6rc2 erkennt er die laufwerke problemlos ohne hal.

----------

## Christian99

ich hab udisks installiert und udev und dbus neu gestartet. hat nix gebracht.

wie kommst du eigentlich darauf? für mich sind "storage devices" eher usb-sticks und -festplatten und keine optischen laufwerke. außerdem find ich bei k3b nirgends einen hinweis da drauf.

----------

## Josef.95

Hallo Christian

Wenn du noch kde:4.5 verwendest dann benötigst du noch HAL und auch den gestarteten hal Daemon,

ja auch wenn du schon das brandneue app-cdr/k3b-2.0.2 Ebuild verwendest.

Ein Einsatz ohne HAL ist wohl erst ab kde:4.6 möglich. (funkt auch hier für meine Bedürfnisse auch schon einwandfrei   :Very Happy:   )

Zudem prüfe noch mal ob dein User auch in der cdrom Gruppe ist!

----------

## Christian99

achso, dann werd ich mal noch ein bischen warten und hoffen, dass 4.6 möglichst bald rauskommt. Schönen Dank

----------

## franzf

 *Christian99 wrote:*   

> achso, dann werd ich mal noch ein bischen warten und hoffen, dass 4.6 möglichst bald rauskommt.

 

Noch eine Woche, wenn alles klar geht (schaut wohl so aus):

http://techbase.kde.org/Schedules/KDE4/4.6_Release_Schedule

----------

## Christian99

na, dann bleibt ja nur zu hoffen, dass die package manager flott sind, aber das war ja bisher noch nie ein problem  :Smile: 

----------

## Josef.95

Falls wem das ganze noch ein wenig näher interessiert - siehe zb auch

http://www.kde.org/announcements/announce-4.6-beta1.php

 *Quote:*   

> KDE Frameworks 4.6 Beta1 Previews Support for upower, udisks and udev
> 
> The two most significant changes in the KDE development frameworks 4.6 release targets the move away from HAL, which is being phased out by many Linux vendors, towards the u* hardware abstraction components.
> 
>     * The introduction of device targets makes it easier to customize build and installation of KDE's frameworks, providing leaner install options for mobile target devices. By reducing dependencies between libraries that together form the KDE Platform, these parts become usable individually, thanks to a higher degree of modularization.
> ...

  (Auszug)

----------

## Christian99

yeah, mit 4.6 ist alles gut, k3b läuft wieder, hurra!!

Leider musste ich für 4.6 jetzt endgültig akonadi installieren. bisher hab ich mich erfolgreich davor gedrückt  :Sad: 

----------

## mv

 *Christian99 wrote:*   

> Leider musste ich für 4.6 jetzt endgültig akonadi installieren. bisher hab ich mich erfolgreich davor gedrückt 

 

Bei libkworkspace (das kdelibs[semantic-desktop] haben will) interpretiere ich einen "FIXME"-Kommentar so, dass diese Abhängigkeit verschwinden könnte, sobald die activities in kdelibs sind. Daher warte ich noch mit dem Update und hoffe auf Vernunft bei den KDE-Entwicklern, dass zumindest kdm, k3b, und der Basis-Workspace ohne nepomuk-Installation lauffähig sind.

Was aber auch viel zu wenig bekannt ist: Mit dem *kit-Geraffel handelt man sich die äußerst unangenehme udev[extras]-Abhängigkeit ein, die sys-apps/attr und sys-apps/acl in das System zwingt. Für jemanden, der einen Rechner mit Unix-Rechten (und nicht mit XFS-Rechten) administrieren will, ist es keine gute Idee, SUID-Programme (oder init-Programme) zu haben, die diese Bibliotheken nutzen...

----------

## Necoro

 *Quote:*   

> Was aber auch viel zu wenig bekannt ist: Mit dem *kit-Geraffel handelt man sich die äußerst unangenehme udev[extras]-Abhängigkeit ein, die sys-apps/attr und sys-apps/acl in das System zwingt. Für jemanden, der einen Rechner mit Unix-Rechten (und nicht mit XFS-Rechten) administrieren will, ist es keine gute Idee, SUID-Programme (oder init-Programme) zu haben, die diese Bibliotheken nutzen...

 

Könntest du das bitte etwas genauer ausführen? Oder einen Link zu einer Erklärung geben?

----------

## mv

 *Necoro wrote:*   

> Könntest du das bitte etwas genauer ausführen?

 

Ist nicht offensichtlich, was ich meine? Wenn ich auf meinem Filesystem nur die Unix-Rechte haben will (also die üblichen User/Group/Other/sticky bit/SUID), aber eben keine ACLs oder andere Mechanismen zur Rechtevergabe, dann sollte ich auch keine Programme haben, die diese alternativen Rechte im Dateisystem modifizieren können.

Selbst wenn die Programme das "normalerweise" nicht modifizieren würden, so könnte doch ein Bug oder Exploit dafür sorgen, dass sie es irgendwann doch tun. Wenn man ein System administriert, dessen Rechteverwaltung ACL-basiert ist, ist das natürlich in Ordnung. Aber wenn man kein solches System hat (und das sind die meisten Ein-Benutzer-Desktops), ist es ein unnötiges Sicherheitsrisiko, einen überflüssigen (weil auf dem System nicht benötigten) Komplexitätslayer einzufügen.

----------

## Necoro

Nein - ich hatte wirklich nicht gesehen, auf welche Problematik du anspieltest  :Smile: . Danke für die Ausführung.

----------

## Christian99

für was braucht das "*kit"-Geraffel das dann überhaupt, wenn es optional ist das zu verwenden?

----------

## mv

 *Christian99 wrote:*   

> für was braucht das "*kit"-Geraffel das dann überhaupt, wenn es optional ist das zu verwenden?

 

Für Systeme, die ACL benutzen, ist das Setzen natürlich schon sinnvoll. Offensichtlich baut RedHat schon seit langem auf ACL für ihren "fast user switch", und polkit & co. sind m.W. hauptsächlich für RedHat entwickelt worden. Da hatten die Entwickler offensichtlich keine Motivation, einen ./configure-Switch einzubauen, der die Benutzung der Library optional macht. Man darf eigentlich schon dankbar sein, dass sie wenigstens pam nur optional anfordern.

----------

## Randy Andy

Hi mv, (und natürlich alle Anderen)

da ich hier offenbar gerade den richtigen an der Strippe habe, möchte ich gern diese Frage stellen, wenn auch vielleicht ein bisschen OT, kann man ja dann auch gern verschieben.

Ich brauch noch als Argumentationshilfe (für eine Gentoo-Vortrag in meiner LUG)  folgende Info, über die ich bisher nichts konkretes in der devel-doku zum Thema ebuilds finden konnte:

Sind grundsätzlich alle verfügbaren ./configure switches in einem ebuild als USE-Flags abgebildet (auch wenn es dort zu Namensabweichungen kommen kann, weil es Zusammenlegungen gibt)?

Wer prüft das, wie ist die Richtlinie, kann man sich darauf verlassen, oder muss man sich doch von jedem Paket die switches anschauen?

Wird hier bei der Verifizierung der USE-Flags vor der Aufnahme in den offiziellen Tree geprüft, im Gegensatz zu den Overlay-ebuilds?

Fragen über Fragen   :Wink: 

Ich konnte nur was zu den Regeln finden, wie es zur Aufnahme von globalen USE-Flags kommt, und dass das Automagic der Pakete in jedem Fall abgefangen werden muss, etc.

Vielen Dank, bin gespannt.

Andy.

----------

## Necoro

 *Randy Andy wrote:*   

> Sind grundsätzlich alle verfügbaren ./configure switches in einem ebuild als USE-Flags abgebildet

 

Nein. Welche abgebildet werden liegt im Ermessen des Devs.

```
econf --libdir=/usr/$(get_libdir)/${PN} \

        --enable-lfs \

        $(use_enable ipv6) \

        $(use_with bzip2) \

        $(use_with fam) \

        [...]
```

----------

## Randy Andy

Danke Necoro.

Ich befürchtete schon dass die Antwort darauf in diese Richtung gehen würde.

Darf ich noch eine Frage anknüpfen.

Wie kann ich erfahren welche die Default-Settings eines Paketes sind (nicht Gentoo-spezifisch), denn ein ./configure --help zeigt mir ja lediglich den dokumentierten Teil an, und oft genug 

fehlen dann Hinweise auf die default Vorgaben.

Ansonsten Dank für deine Beispielsyntax. Werd's mal test wenn ich wieder vor einem vernünftigen OS sitze   :Wink: 

Gruß, Andy.

----------

## franzf

Viele configure-Optionen werden auch direkt in den eclasses gesetzt. Teilweise werden auch USE-Flags dort hinzugefügt (z.B. linguas in qt4-r2.eclass, "debug pch aqua" in qt4-build.eclass, usw).

Genauso sind USE-Flags nicht immer Build-Optionen. Dadurch können auch PDEPENDS aktiviert werden ("policykit" in kdelibs verlangt NACH der Installation von kdelibs die Installation von 2 polkit-kde-*-Paketen), oder vom eigentlichen SRC-tarball unabhängige Pakete mit in die Installation einbezogen werden ("editor"-Flag bei xmoto lädt ein separates Paket herunter, in dem eine inkscape-Erweiterung zum Bauen von xmoto-Levels enthalten ist).

Das endgültige Wort, was jetzt wie umgesetzt wird hat der Maintainer des jeweiligen Pakets, Wünsche und Fixes können aber natürlich auch von Usern kommen (bugs.gentoo.org, direkter Draht zum Maintainer).

----------

## Necoro

 *Randy Andy wrote:*   

> Wie kann ich erfahren welche die Default-Settings eines Paketes sind (nicht Gentoo-spezifisch), denn ein ./configure --help zeigt mir ja lediglich den dokumentierten Teil an, und oft genug fehlen dann Hinweise auf die default Vorgaben.

 

Ich würde sagen: Im schlimmsten Fall durch Studium der entsprechenden Skripte. Denn es soll ja auch Pakete geben, die keine autotools verwenden  :Smile: . Also prinzipiell wird es wohl keinen "garantierten" Weg gehen.

 *Quote:*   

> Ansonsten Dank für deine Beispielsyntax

 

War ein Auszug aus dem lighttpd-Ebuild. Ich denke, dass du fast in jedem größeren Ebuild fündig wirst. (Von den Switches, die der Maintainer gar nicht kennt und die deswegen vom configure-Skript automatisch gesetzt werden mal ganz zu schweigen).

----------

## Randy Andy

 *Necoro wrote:*   

> 
> 
> War ein Auszug aus dem lighttpd-Ebuild. Ich denke, dass du fast in jedem größeren Ebuild fündig wirst. (Von den Switches, die der Maintainer gar nicht kennt und die deswegen vom configure-Skript automatisch gesetzt werden mal ganz zu schweigen).

 

Ich habe beim lesen dieser Quelle: http://devmanual.gentoo.org/general-concepts/use-flags/index.html

Diesen Auszug: *Quote:*   

> 
> 
> Packages should not configure and link based upon what is available at compile time — any autodetection must be overridden. This is commonly referred to as the dependency being "automagic" - This is bad because the dependency is not detected by the package manager tools and can easily break, among other issues. 

 

so verstanden dass diese automagic die du andeutest auf jeden Fall geprüft und unterbunden werden soll.

@Franz

Das mit den eclasses muss ich mir wohl nochmal ausführlicher zu Gemüte führen, um es besser verstehen und nachvollziehen zu können.

Dank Euch erstmal für die Hinweise.

----------

## Necoro

 *Randy Andy wrote:*   

> so verstanden dass diese automagic die du andeutest auf jeden Fall geprüft und unterbunden werden soll.

 

automagic sachen auf jeden Fall. aber zB dass ein Paket anbietet ein bestimmtes Feature abzuschalten und dafür auf eine Dependency zu verzichten: Wenn der Maintainer nicht weiß, dass es so einen Schalter gibt (zB weil das zwischen zwei Versionen und ohne Ankündigung geschehen ist), denn kann er auch kein Useflag einführen. Ein Problem wird es nicht geben, da die Dependency ja immer da ist (sie steht ja schon im Ebuild).

----------

## Randy Andy

Tja,

ist halt doch ziemlich aufwändig alle Optionen zu prüfen und in das ebuild einfließen zu lassen, und dann noch alle mögliche Änderungen nachzuhalten.

Da muss man schon vertrauen in die Gewissenhaftigkeit der Paket-Maintainer haben, wenn man nicht alles selbst überprüfen möchte, und wer will das schon   :Wink: 

Da wundert mich auch nicht mehr die geringere ebuild-Anzahl verglichen mit Debian der Paketauswahl von Debian, rührt sicher auch von dem größeren Aufwand her, von dem zeitlichen Vorsprung mal abgesehen, wo wir doch erst etwas über 10 Jahre Jung sind.

Wie mag das eigentlich bei den binären Distros ablaufen, übernehmen die fast immer die Einstellungen per ./configure um ihre Pakete zu bauen?

Das ist ja deutlich einfacher, hat aber leider viel mehr Abhängigkeiten, und dann noch externe, die ja nicht wie bei uns nach dem erfolgreichen Bau aus den Quellen zwangsläufig erfüllt sind  :Rolling Eyes: 

----------

## Necoro

 *Randy Andy wrote:*   

> Da wundert mich auch nicht mehr die geringere ebuild-Anzahl verglichen mit Debian der Paketauswahl von Debian

 

Dafür ist es sicherlich einfacher sich selber ein Ebuild zu schreiben, wenn man es braucht als ein .deb-Paket zu basteln, oder?  :Smile: 

----------

## Randy Andy

Full ack.

----------

