[Sturmovik]

Der Paketmanager sagt dir doch was er installiert. Und wenn du ihn mit den richtigen Fragen löcherst, dann sagt er dir auch warum welches Paket installiert ist.
'aptitude why' ist hier ein Stichwort. Also intransparent ist für mich was anderes.

Wäre es dir lieber, wenn da in der Doku 568 Paketabhängigkeiten aufgeführt wären, die du erstmal selbst installieren darfst, damit Opsi funktioniert?

Dann müsste man erst gar kein Paket bauen, sondern einfach dem User die zig Abhängigkeiten auflisten und die eigene Software als Blob/Source hinwerfen.
Ich kenn da einige andere Projekte, die so verfahren... grauenhaft. Erstrecht wenn die Doku gern mal vom aktuellen Stand abweicht und dann die Abhängigkeiten nicht mehr stimmen.

---

Ich wüßt jetzt auch nicht was man an open source falsch verstehen kann. Quellcode ist frei verfügbar. Mehr besagt dieser Begriff nicht. Der Rest hängt a) von der Lizenz ab (jaja, das Lizenzchaos) und b) vom Willen der Entwickler, deine Patches anzunehmen.
Sicherlich gibts noch ein c) und d)

Dieser Beitrag wurde von Sturmovik bearbeitet: 17. Dezember 2015 - 21:53

[RalphS]

Der Paketmanager sagt mir das erst, wenn ich den Paketmanager auch hab. Heißt, wenn ich das wissen will muß ich erst die VM einrichten (oder die freundlicherweise bereitgestellte VM ausführen). Will ich aber nicht, ich will wissen was da hinter los ist.

Gut, kann das natürlich erst nach näherem Anschauen beurteilen wieviele Tausende Abhängigkeiten da dahinterstehen (oder auch nicht). Aber ein simples "setzt hier auf" und/oder "dann tut das so" etc pp würd ja schon reichen. Nur halt was mehr als "ja man braucht MySQL und mit Python hats auch was zu tun".

- Ansonsten, ja genau. Open Source wie der Quellcode ist offen. Nicht "frei" - nur "offen"; "free software" mag zwar "open source" sein aber halt nicht notwendigerweise andersherum.

Ich will auch kein Paket sondern eben jenen Quellcode... oder zumindest einen Hinweis wie ich den kriegen kann, und sei es nur per "ja den kriegt man so-und-so lizensiert". Aber...

Denn ich will wissen, ob und ggf wie ich das Zeug ggf auf meine Umgebung portiert krieg. DAZU soll open source da sein.

[Sturmovik]

Den Paketmanager brauchst du gar nicht. Die Abhängigkeiten (fürs Binärpaket) stehen im Paket in Klartext drin. Jeder halbwegs brauchbare Entpacker der letzten 30 Jahre sollte auch das ar-Format beherrschen, in dem .deb gepackt ist.

Ansonsten heißts im Code buddeln, was da so benutzt wird. Oder einfach mal die Entwickler fragen. Die sollten dir verraten können, welche Buildchain benötigt wird und was das fertige Produkt so zum laufen braucht.
Eventuell ists sogar irgendwo niedergeschrieben. Soll ja Programmierer geben, die ihr geschreibsel dokumentieren

Wo du den Code herbekommst hab ich dir ja oben verlinkt.

NB: open-source heißt nicht zwangsläufig portabel. Dein geheiligtes BSD tickt an einigen Ecken anders als Linux, da scheiterte schon somanches beim portieren. In beiden Richtungen.

Die Jungs von Debian haben nicht umsonst ihre Bemühungen vorerst eingestellt, den BSD-Port weiter zu pflegen. Da haben einfach zuwenige Bock auf den Stress.
Edit: Oha, da war ich wohl nicht ganz up to date. Anscheinend haben sich doch genug Wahnsinnige gefunden, um Jessie zu porten

Dieser Beitrag wurde von Sturmovik bearbeitet: 17. Dezember 2015 - 23:49

[RalphS]

Mh? Was? Sorry, nö, "mein geheiligtes BSD" hat damit gar nix zu tun und ich bild mir zumindest ein, nicht so verblendet zu sein, dessen Ecken und Kanten nicht auch als Ecken und Kanten zu erkennen ... und mich drüber aufzuregen.

glibc ist ein prima Beispiel. Daß es geht, sieht man ja. Wobei mir das bei debian immer eher wie ein proof-of-concept schien.

- ANYWAY darum gings ja auch gar nicht. Sondern darum, daß imo opensource nicht frei sein *muß* - klar, *kann*, und ist auch toll wenn es das ist, aber halt eben nicht *muß*. Das ist auch schon alles und hat mit BSD nicht viel zu tun.

Ehrlich gesagt weiß ich grad gar nicht worüber wir überhaupt diskutieren Denn das .deb-Format kenn ich gut genug um zu wissen wo was ist, und wie gesagt ich bin gern bereit anzuerkennen den Quellcode einfach *übersehen* zu haben bisher (nicht die Binärpakete).

Leben und leben lassen, und so. Ich mein, so oder so werd ich mir die opsi-Sache angucken, wenn ich Zeit dafür finde - find ich nämlich wahnsinnig interessant und während der SCCM zwar toll ist und "alles" kann, so ist er aber auch komplett unhandlich und frißt Ressourcen als gäbs kein Morgen und ist auch für kleinere Umgebungen komplett überdimensioniert... weswegen erstmal jede potentielle Alternative willkommen ist. Und egal wie man sichs dreht, eine Appliance bereitzustellen ist schon so perfekt (für mich als Nutzer) wie man sichs nur wünschen kann, weil es da drin ganz einfach erstmal funktioniert zu Antesten.

Was mich aber halt stört ist die (scheinbare?) Bindung an nicht mal Linux sondern halt ganz konkret debian-basierte Systeme, wo wir wieder bei der Portabilität sind - und in diesem Fall nicht im Sinne von Unixoid-zu-Windows oder BSD-oid zu Linux-oid oder sonstwas, sondern tatsächlich im Sinne von "hier haben wir ein Stück Software, was nicht mal von Linux zu Linux portiert werden kann". Was, wenn es denn so sein sollte, sogar dem Linux-Konzept *selber* entgegensteht.


ANYWAY moin und ich hoffe einfach mal nicht wem auf die Füße getreten zu sein, das war und ist nicht mein Anliegen gewesen.

[Sturmovik]

Ok, da haben wir wohl aneinander vorbei geschrieben. Ich hatte angenommen, dass du das Ding auf BSD portieren willst.

Den Quellcode wirst du im .deb wohl kaum finden, dafür gibts ja normalerweise Source-Pakete. Deswegen hab ich ja hierher verlinkt: https://svn.opsi.org/

Wobei du eventuell gar nicht selbst bauen musst, sofern du unter dem anderen System, sei es rpm-basiert oder irgendwas anderes, sofern du die Abhängigkeitskette komplett bekommst. (Und sich nix anders verhält als unter Debian)
Auf so Spezialitäten wie SE-Linux geh ich jetzt mal nicht ein, obwohl die natürlich alles kaputtmachen können.

Ist ja andersrum das gleiche. Ich hab hier Software, die nur als rpm angeboten wird, während fast alle meine Systeme debianoid sind (bis auf die Drecks-SLES-Kisten)
Dank alien alles kein Problem.

---

Dass Opsi nur für Debianoide verfügbar ist, dazu hab ich einen Verdacht. Das ist ja kein wirkliches Linux-Projekt, sondern ein Werkzeug für Windows-Umgebungen.

[spekulatius]Deswegen ham die sich den Ubuntu-Server hergenommen, da das in der Volksmeinung die einfachste Variante für nicht-Linuxer ist. Und weil der recht nah an Debian dran ist, funktionierts eben auch unter Debian.
Pakete für andere Distros bauen? Warum, wir bieten ja die Appliance an... [/spekulatius]

Ehrlich gesagt finde ich das schonmal positiv, dass überhaupt Installations-Anleitungen vorliegen. Andere verfolgen da eher eine Friß-oder-Stirb-Mentalität: "Nimm die Appliance oder lass es bleiben"
Neulich erst mit Bitdefender erlebt. Und dann funktioniert die Appliance nichtmal.

Edit: Grade nochmal in die Doku reingeguckt... Das ist doch für so ziemlich alle ernstzunehmenden Distros verfügbar. Also muss da nix portiert werden.
Und mal ernsthaft, wer sich im Enterprise-Umfeld einen Gentoo/Arch/Linuxfromscratch/whatever-Server hinstellt, hat entweder viel zu viel Zeit oder ist Wahnsinnig.

Dieser Beitrag wurde von Sturmovik bearbeitet: 18. Dezember 2015 - 12:33

[DK2000]

Ui, viel zu lesen am Morgen vor dem Mittag.

Moin zusammen.

[Sturmovik]

Moin Tiger

[DK2000]

Moin Sturmi. Und Ralphi.

Wieviel DVDs muss ich den da für Jessie herunter laden? Alle 3 oder reicht die eine?

32bit/64bit ist ja egal, oder?

[Sturmovik]

DVD1 reicht. Da ist alles drauf, man normalerweise braucht, den Rest gibts ja dann im Repo.
Bei ner halbwegs schnellen Internetverbindung kannst du auch die kleine Netinstall-ISO nehmen und den Rest ausm Repo ziehen.

Außerdem würd ich immer 64bit nehmen. Falls 32bit-Unterstützung gebraucht wird, kann man das nachträglich aktivieren

[DK2000]

Na, dann werde ich mal versuchen, Jessie in der VM anzusiedeln. Anders geht es mangels Rechner gerade nicht. Mal schauen, was passiert.

[Sturmovik]

Ähm, kleiner Hinweis: Wenns unter VMware mit EFI-Emulation installiert wird, spackt der Grafiktreiber beim ersten Booten. Da hat VMware irgendwo Mist gebaut. Du kommst dann nur noch über SSH ins System rein.
Da muss in der Kernel-Commandline was angepasst werden, aber was genau hab ich grad nicht im Kopf.

[DK2000]

Ja, das ist mir auch schon aufgefallen, weswegen ich da bei VMWare BIOS verwende. EFI nehme ich nur dann, wenn es unbedingt sein muss.

[Demonia]

Ich bin Fahrdienstleiterin

[DK2000]

Herzlichen Glückwunsch.

[Sturmovik]