binärpakete + sourcecodes => gemeinsamer manager

[flashbeast]

Hallo!

Mir fiel es nicht einfach, einen passenden Titel zu finden; in einem anderen Thread (klick (http://www.linuxforen.de/forums/showthread.php?s=&threadid=108701)) wurde diskutiert, ein gemeinsames Paketsystem für alle Distributionen einzuführen, um die Interoperabilität zu erleichtern. Nun kam mir aber der Gedanke, dass nicht die verschiedenen Formate (.deb, .rpm etc.) das Problem sind, sondern vielmehr die Verbindung zwischen Sourcecode und Binärpaketen.

Das Ausgangsproblem besteht darin, dass von einigen Programmen nur der Sourcecode verfügbar ist und es keine vorkompilierten Pakete gibt bzw. nicht für die eigene Distribution - für Neulinge sicherlich eine frustrierende Hürde. Die Softwareinstalltion ist ja auch eines der Hauptkritikpunkte an Gnu/Linux.

Tarballs sollen so einfach zu installieren sein wie rpm's, also mit dem spezifischen Paketsystem gekoppelt werden. Das kann von Distribution zu Distribution unterschiedlich aussehen, ich bin bspw. 'urpmi' von Mandrake gewohnt; "unter der Haube" dagegen sind sie voll miteinander kompatibel.

Anwendungsbeispiel:

urpmi programm
precompiled programm not found. download and install tarball? y/n
loading...
installing...
done.

Erläuterung: in der urpmi-Datenbank (bzw. den FTP-Servern) wurde nichts gefunden. Stattdessen wird auf den FTP's gesucht, die die Quellen bereitstellen, welche verbreiteter sind, da sie ja für alle Distributionen geeignet sind. Falls die Datei auch dort nicht vorhanden ist ('programm' not available), wird man darauf verwiesen, das Programm direkt von der Hersteller-/Entwicklerseite zu installieren. Dies sieht dann ebenfalls wie bei .rpms aus:

urpmi Programm.tgz bzw. urpmi http://www.hiergibtesultrasexyprogramme.de/download/Programm.tgz

Das Programm wird dann wie bei nem (rpm-)FTP installiert, gegenfalls auch erst runtergeladen/gecached (2. Fall).

Abhängigkeiten: diese werden wie bei .rpms automatisch gelöst.

Vereinheitlichung: Die Tarballs haben ein einheitliches Format/eine einheitliche Verzeichnisstruktur usw.; dabei kann es auch ein .zip oder .rar sein, Hauptsache der Inhalt stimmt

Ähnliche Systeme: mag sein, dass das System von Slackware oder Gentoo diese Zwecke erfüllt, jedoch sollte es Distributionsunabhängig sein; wie eine einfachere Implementation von checkinstall (hab ich aber noch nie benutzt):

Es soll nicht vollautomatisiert werden, sondern einfach
1.) das config, make, make install und make uninstall zu vereinfachen und
2.) in die Datenbank des bisherigen Paketformats (rpm, deb,...) integriert werden. Man hat vorher eine Option (z.b. Checkbox), mit der man festlegen kann, dass Abhängigkeiten erfüllt werden und danach gesucht wird usw.; man sollte optional und transparent schauen können, was der Installer macht; ausserdem sollte es einen Expertenmodus geben, wo man Attribute setzen kann etc.

Es soll nicht primär für Leute gedacht sein, die sich damit gut auskennen (oder Kontrollfreaks ;) ), sondern für Neulinge (oder Faule), die mit .rpms zufrieden sind und auch mal Software installieren wollen, für die es keine vorkompilierten Pakete gibt (bzw. Binärpakete, die inkompatibel mit der eigenen Distribution sind).

Ich möchte also ein einheitliches Management haben, dass Sourcen und Binärpakete verbindet, dabei aber die spezifischen Eigenschaften der Distributionen berücksichtigt. Distributionen können hoch angepasst / modifiziert sein - das Programm wird eben an die Distribution angepasst (z.B. Pfade), aber die Kompatibilität wird bewahrt.
Das Programm soll dabei möglichst einfach (komfortabel) gehalten sein, am besten noch zusätzlich mit einem (oder mehreren verschiedenen) grafischen Frontend.

Ich würde gerne eure Meinung dazu hören :)

Gruß, flashbeast


p.s.: bitte verhaut mich nicht, ich habe noch nicht so die Überahnung von GNU/Linux ;); ist nur der bescheidene Wunsch eines Durchschnittsusers...

p.p.s.: ich hoffe dass das das richtige Sub-Forum ist, ansonsten -> move

[sirmoloch]

Ich wusste ja gar nicht, was ich mit meinem Beitrag ausgelöst habe...:D:ugly: Aber die Idee gefällt mir!

[flashbeast]

so... (scheint zwar eh keinen zu interessieren, aber was solls :ugly: )
hab mal nen ersten entwurf gemacht. fragt mich nicht, wieso ich es auf englisch gemacht hab - hat sich so ergeben (wegen dem close-button):

http://mitglied.lycos.de/TLJ/Pictures/screenshots_desktop/pkmng06.png

erklärung: die kategorien lassen sich "einfahren" wie üblich mit dem dreieck; das ist allerdings rechts unten, nicht links. wenn man auf update klickt, popt ein dialogfeld auf (mach ich später), bei bestätigung schließt es sich, und statt denn buttons "update" und "uninstall" erscheint ein fortschrittsbalken, statt der größe steht dann was er gerade macht (downloading, updating), evtl. noch ein "details"-button über die genaue downloadgeschwindigkeit, quellenangabe/-adresse, infos darüber wo er grad was macht etc.)

pakete lassen sich auch als gruppe selektieren und deinstallieren/updaten, man markiert sie einfach mit shift oder zieht einen mausbalken über die programmname, mit rechtsklick kommt man dann in ein kontextmenü, alternativ kann man mit den vorgegebenen buttons eines beliebeigen markierten pakets die aktion starten.

rechts werden infos zu einem markierten programm angezeigt (linksklick), über "go to programm folder" öffnet sich ein neues fenster, welches per reiter die einzelnen verzeichnisse anzeigt (/usr/bin, /etc/programmname usw.) und zugriff auf die dateien des programms gewährt, ohne extra einen dateibrowser öffnen und sich durchhangeln zu müssen (idee stammt u.a. von gnome)

*edit: die komponenten eines programms (z.b. xine-plugins) werden auch über die programmfelder erreichbar sein; vielleicht auch per dropdown wie bei den kategorien. werd es später mal hinzufügen.

[drunkenPenguin]

He, mich interessiert das! Hast Du da was gecodet, oder was für ein Bild ist das?? Oder ist das urpmi (hab kein Mandrake)?

Gruß,
Daniel

[flashbeast]

ne sorry, kann leider nicht (bzw. nur sehr wenig java) programmieren. das obige ist nur zusammen-gegimpt, eine art skizze. ich werde sie im laufe der woche noch vervollständigen, es soll nur ungefähr ne struktur sichtbar sein. die "technik", die dahintersteckt ist im eingangspost beschrieben ;)

[sirmoloch]

Wenn du mich fragst wird das zu unübersichtlich. Eine Baumansicht - reiner Text, keine Icons, etc. - würde es bei z.B. 1000 Paketen leichter und effizienter machen.

[flashbeast]

jo klar, es soll ja auch weitmöglichst übersichtlich sein. daher wird auch alles zusammenklappbar sein (das wird dann auch gespeichert), so dass man nicht jedes mal tausende von paketen offen hat.

ausserdem sollen die komponenten zusammengefasst werden (hab ich oben im text editiert; z.b. alles was zu xine gehört [außer globale bibliotheken] ist über xine erreichbar [plugins, skins etc.]), ausserdem sollte es auch ne suchmaske geben (wie bei gängigen rpm-managern).

der clou ist auch nicht (nur) die gui, sondern die technik. z.b. wird es möglich sein, programme aus dem filebrowser per drag&drop in eine x-beliebige kategorie zu packen (man kann kategorien editiern, löschen, hinzufügen etc.).

ausserdem kann man zwischen einer "vereinfachten" (reiner text) und einer "klassischen" (s.o.) ansicht wählen können. das ganze richtet sich auch eher an neulinge, die sich eher an bildern orientieren (geht glaub ich schneller)

[drunkenPenguin]

Hallo,

Jetzt hab ich mal ein wenig drüber nachgedacht.
Die Idee ist an sich nicht schlecht, die Tools sind vorhanden.
Aber ich stelle es mir irrsinnig kompliziert vor ... da wäre es sinnvoller, wenn man bei anderen Distris wie bei Mandrake verfährt: primär rpm-Pakete und sekundär aus den Quellen zu installieren. alien zur Paketumwandlung noch ins Spiel zu bringen, erscheint, zumindest mir, als wenig erfolgversprechend, da die meisten Programme eh schon im Quelltext vorliegen.
Was Du Dir also vorstellst, wäre eine Mischung aus apt und portage mit einem grafischen Frontend. Was man allerdings bräuchte, wäre eine (mehrfach gespiegelte) Datenbank auf ein paar Servern, die dann abgefragt wird (so wie bei urpmi -- ich hoffe, ich habe das richtig verstanden). Das ist aber viel Arbeit. Da musst Du ja zweimal Abhängigkeiten lösen.
Zudem müsste man distributionsspezifische Besonderheiten berücksichtigen.
Aber wie gesagt: ich finde das interessant.

Gruß,
Daniel

[flashbeast]

schön das du interesse hast :)


drunkenPenguin
Die Idee ist an sich nicht schlecht, die Tools sind vorhanden.
das mag sein, aber sie erfüllen oftmals nicht alle der gewünschten kriterien. meißt sind sie distributionsabhängig oder haben einige beschränkungen.


drunkenPenguin
Aber ich stelle es mir irrsinnig kompliziert vor ...
es soll eben total einfach werden - der benutzer bemerkt den unterschied zwischen .rpms und tarballs (welche sourcecode enthalten) gar nicht.


drunkenPenguin
da wäre es sinnvoller, wenn man bei anderen Distris wie bei Mandrake verfährt: primär rpm-Pakete und sekundär aus den Quellen zu installieren.
so hab ich mir das auch vorgestellt: es wird primär auf das von der distribution bekannte format gesetzt, bei mandrake z.b. rpm; diese wiederum sind kinderleicht durch urpmi zu insallieren; sourcen dagegen tauchen nicht in der software-datenbankl auf und lassen sich daher auch nicht so leicht entfernen, wenn man die quellen gelöscht hat. es ist bestimmt vergleichsweise einfach zu realisieren - hab gelesen dass checkinstall bspw. sourcen kompiliert und in ein .rpm umwandelt. allerdings sollte dieser umweg für den user irrelevant sein - er gibt nach wie vor ein "urpmi programmname" ein; es wird höchstens darauf hingewiesen, dass es kein vorkompiliertes paket gibt; und auf der anderen seite kann man auch lokal gespeicherte tarballs einspeisen, a la "urpmi programm.tar.gz" - das lästige configure, make, make install und das noch lästigere abhängigkeiten auflösen würde dadurch entfallen.


drunkenPenguin
alien zur Paketumwandlung noch ins Spiel zu bringen, erscheint, zumindest mir, als wenig erfolgversprechend, da die meisten Programme eh schon im Quelltext vorliegen.
es sollen aber x-beliebige quelltexte, also tarballs wie sie jetzt schon für alle distributionen verfügbar sind, einsetbar sein, und nicht irgendwelche auf eine distribution angepassten quellen wie bspw. bei gentoo.


drunkenPenguin
Was Du Dir also vorstellst, wäre eine Mischung aus apt und portage mit einem grafischen Frontend.
ich glaub portage kann sowohl binär- als auch 'quellen' installieren, nur weiß ich nicht ob es auf an die distribution angepasste quellen beschränkt ist.


drunkenPenguin
Was man allerdings bräuchte, wäre eine (mehrfach gespiegelte) Datenbank auf ein paar Servern, die dann abgefragt wird (so wie bei urpmi -- ich hoffe, ich habe das richtig verstanden). Das ist aber viel Arbeit. Da musst Du ja zweimal Abhängigkeiten lösen.
ja das stimmt. neben den distributions-spezifischen servern (z.b. urpmi, debian, gentoo) gibt es dann aber server, die für ALLE distributionen verfügbar sind, da ja die quelltexte ungebunden sind. ausserdem kann man von kleineren projekten, die nicht gespiegelt sind, die programme runterladen; benötigte libraries sind ja oft auch als binärepakete verfügbar, und wenn nicht (z.b. falsche distribution) eben als quellen usw.
bereits jetzt sind die rpm-archiv ja enorm (rpmseek, rpmfind etc.), da dürfte ein quellarchiv ja nicht so das problem sein.


drunkenPenguin
Zudem müsste man distributionsspezifische Besonderheiten berücksichtigen.
dafür ist das programm zuständig. es wird an die gegebenheiten der distribution angepasst (z.b. pfadangaben), so dass es nach innen angepasst, nach aussen aber voll kompatibel ist (also die pakete unabhängig von der distribution benutzbar sind)

*edit: hab's mal ein wenig geändert ;) :

http://mitglied.lycos.de/TLJ/Pictures/screenshots_desktop/pkmng06c.png

[flashbeast]

so hier mal ein paar "zwischenstücke":

rechtsklick-dialog:

http://mitglied.lycos.de/TLJ/Pictures/screenshots_desktop/pkmng_rechtsklick_dialog.png

der uninstall-dialog:

http://mitglied.lycos.de/TLJ/Pictures/screenshots_desktop/pkmng_uninstall_dialog.png

der update-dialog:

http://mitglied.lycos.de/TLJ/Pictures/screenshots_desktop/pkmng_update_dialog.png

der update-prozess:

http://mitglied.lycos.de/TLJ/Pictures/screenshots_desktop/pkmng_update_in_prograss.png

die installationskomponente kommt später...

[ml]

Hallo!

Funktioniert das schon?
Oder nur zusammengegimpt?

mfg

ml

[flashbeast]

leider letzteres, da nur sehr geringes interesse. :(

[ml]

Ich hätt schon Interesse.

mfg

ml

[flashbeast]

dann kannst du es ja programmieren :D

[peschmae]

Geringes Interesse im Sinne von: "Mein apt-get funktioniert bestens und erst noch auf der Konsole :)"

MfG Peschmä

[klo8]

Großes Intresse im Sinne von "Mein rpm geht mir sehr am Nerv und ich will Gentoo bzw. Portage für Fedora!"
Ich stell mir das wie im Paradies vor, keine Dependencies mehr.:ugly:
Ahja, ich habe gerade ein merkwürdiges Problem mit xine gehabt. Ich hab mir xine als rpm heruntergeladen, kaum starte ich Installation (Fedora Core 1) schreibt er, er braucht xine-skins. Zieh ich mir jenes. Starte ich rpm-Installation, was schreibt er, er braucht xine. Dann musste ich Linux-Noob (besser gesagt rpm-Noob :ugly: )
nachfragen. So bekam ich folgenden Tipp: Wenn zwei Pakete sich gegenseitig benötigen, muss man sie über die Konsole installieren (Schema: rpm -i paket1 paket2) .
Gesagt getan. Jetzt braucht xine aber noch irgendwelche libs, z.B. libxine und libaa, die ich beide über google nicht als Quelltext und Fedora-kompatibles rpm finden konnte.
Gruss,
klo8

[peschmae]

Großes Intresse im Sinne von "Mein rpm geht mir sehr am Nerv und ich will Gentoo bzw. Portage für Fedora!"


Huh? Und wieso installierst du dir dann nicht einfach Gentoo?

Oder benutzt zumindest apt, um dir das Leben ein bisschen leichter zu machen?

MfG Peschmä

[kth]

Original geschrieben von klo8
Großes Intresse im Sinne von "Mein rpm geht mir sehr am Nerv und ich will Gentoo bzw. Portage für Fedora!"Für Fedora gibt's schon apt, yum, up2date und zahlreiche Repositories.
Ich stell mir das wie im Paradies vor, keine Dependencies mehr.:ugly:Aua. Auch Portage arbeitet mit Abhängigkeiten; guck mal hinter die Kulissen.

Zu deinem Problem mit xine: Lies mal http://www.linuxforen.de/forums/showthread.php?s=&threadid=113149, damit du apt-get install xine, yum install xine oder up2date xine machen kannst. Dann werden die Abhängigkeiten automatisch aufgelöst.

[flashbeast]

im endeffekt wäre es - meiner meinung nach - am sinnvollsten, wenn es einen vordefinierten pool an populären bibliotheken gibt, sprich: die größten bibliotheken zusammengefasst. die übrigen, kleineren werden dann einfach lokal an das paket gebunden, so dass man den abhängigkeiten-kudelmudel gar nicht mehr beachten muss. es ist doch bescheuert, dass ich programm a wegen programm b deinstallieren muss, nur weil bibliothek c upgedated werden muss (so geschehen mit nicotine und eroaster). oder eben eine plattformunabhängiges portage-system, das v.a.D. die anfänger anspricht und ihnen die drecksarbeit abnimmt.

[flashbeast]

falls es noch wen interessiert - den gleichen gedankengang hatte der autor dieser kollumne (http://madpenguin.org/Article930.html)

[Susu]

Also ich habe ehrlich gesagt kein Interesse daran. Warum wollt ihr ein Distri-übergreifendes Paketmanagement, wenn ihr im gleichen Atemzug über Windows und seine *.exe lästert? Einerseits gibt es sowas z. T. schon. So kann Debian sowohl mit Binärpaketen als auch mit Sourcen umgehen (Stichwort: apt-get -b source Paketname). Andererseits wüßte ich auch nicht, ob sich das überhaupt sinnvoll und Distri-übergreifend realisieren lässt.

Ich persönlich bevorzuge die Freiheiten und Pflichten, die mir die verschiedenen GNU/Linux-Systeme bieten und suche mir halt das raus, womit ich am besten umgehen kann.

Susu

[stefan-tiger]

Die Bilder sehen recht gut aus, aber bitte versucht mal folgendes "Problem" zuerst zu lösen:

Warum kann man ein SuSE 8.0 rpm nicht unter SuSE 9.0 installieren?

Wie soll "euer neues" Paketsystem dieses Problem lösen?

Gruß

[flashbeast]

Also ich habe ehrlich gesagt kein Interesse daran. Warum wollt ihr ein Distri-übergreifendes Paketmanagement, wenn ihr im gleichen Atemzug über Windows und seine *.exe lästert?
nein, das hast du falsch verstanden. es bleiben die distributions-eigenheiten bestehen. nur die "oberfläche", die oberste schicht, wird vereinheitlich oder zumindest optional vereinfacht, für die "major" distributionen. um z.b. installationen per drag & drop zu gewährleisten. zumindest war das der ansatz, den ich mir so vorgestellt hatte.


aber bitte versucht mal folgendes "Problem" zuerst zu lösen:

Warum kann man ein SuSE 8.0 rpm nicht unter SuSE 9.0 installieren?

Wie soll "euer neues" Paketsystem dieses Problem lösen?
das soll eben genau der knackpunkt sein. es soll kein unterschied sein, was man installiert, und woher - es wird durch den fleischwolf gedreht und auf die distribution angepasst, ganz gleich welche version oder welches paketsystem angewandt wird. warum tausende von gb verschwenden, nur weil ein suse-rpm nicht unter redhat läuft usw.?

[Freekazonid]

kann mir mal jemand die problematik der ganzen geschichte erklaeren? :confused: immer mehr hoehre ich dieses "einheitliche installationsystem" und "bessere installation" bla. wtf einfacher gehts doch wohl nicht?



Das Ausgangsproblem besteht darin, dass von einigen Programmen nur der Sourcecode verfügbar ist

DAS siehst du als problem? Oo

[flashbeast]

JA. ich finde es sehr unkomfortabel, wie es jetzt ist (von gentoo red ich da nicht).

und zum thema einfacher: wenn die aktuellen systeme wenigstens 100%tig zuverlässig funktionieren würden. dies ist aber wegen den tlw. sehr starken abhängigkeiten einfach nicht gegeben. ich kann bspw. amule nicht aktualisieren, ohne mein halbes os zu aktualisieren - das kanns doch nicht sein...

klar ist es einfach zu sagen, dass es leicht ist, wenn man sich lange genug damit beschäftigt hat. aber woanders geht es doch auch - siehe beos oder macosx.

[Freekazonid]

was genau ist unkomfortabel?

1. jede distri hat ihr packetmanagement system. bzw gibt es auch portable (apt). und mit diesen ist es ja wohl super bequem & einfach, software zu installieren/upzudaten/verwalten/deinstallieren etc.

2. fuer sachen die es bei packetmanagement tool NICHT gibt, gibt es die sourcen, verpackt als tar.gz. entpacken & installieren, fertig. wo soll das problem sein? das schaffen auch anfaenger, erzaehl mir nix :rolleyes:

das soll jetzt keine beleidigung oder sonstwas gegen deine programmier arbeit sein, ich progge selber und weiss wie hart sowas ist, also respekt fuer das programm. mir geht es nur um das WIESO

[flashbeast]

was genau ist unkomfortabel?
erzähl ich dir gleich, einen moment ;)


1. jede distri hat ihr packetmanagement system. bzw gibt es auch portable (apt). und mit diesen ist es ja wohl super bequem & einfach, software zu installieren/upzudaten/verwalten/deinstallieren etc.
wenns denn klappt. ich kenne zwar selber kein apt-get, hab aber gelesen dass es auch damit probleme geben soll - unter einigen umständen.
ich hab urpmi eingesetzt und bin - neben dem eigentlichen komfort - auch an diverse probleme gewöhnt, wo sich pakete gegenseitig im weg standen, eben weil abhängigkeiten störten. meinst du ich aktualisier ein 5mb-programm, wo ich erst 300mb installieren muss? ich finde das nicht sehr elegant oder gar komfortabel!


2. fuer sachen die es bei packetmanagement tool NICHT gibt, gibt es die sourcen, verpackt als tar.gz. entpacken & installieren, fertig. wo soll das problem sein? das schaffen auch anfaenger, erzaehl mir nix :rolleyes:
ganz einfach: die sourcen zu kompilieren ist für anwender meist eine ziemliche zwickmühle, nicht selten kommt es zu diversen problemen, und nicht zuletzt wegen den nicht aufzulösenden abhängigkeiten. das führt zum unnötigen spießroutenlauf, und das nicht zu selten. dabei geht jede menge zeit drauf, so dass man sich schnell fragt, ob's dass sein kann. ich weiß nicht ob es da anderen anfängern anders geht, ich jedenfalls war ohne urpmi ziemlich aufgeschmissen und kann behaupten, dass ich nur durch einen gewissen grad an masochismus und v.a.D. viel geduld am ball geblieben bin. das kann man leider nicht von vielen anderen neulingen behaupten :/
von den teilweise langen kompilierzeiten mal abgesehen.


das soll jetzt keine beleidigung oder sonstwas gegen deine programmier arbeit sein, ich progge selber und weiss wie hart sowas ist, also respekt fuer das programm. mir geht es nur um das WIESO
glaub mir - beleidigt hast du mich damit in keinster weise. es gibt eben genug leute - mich einschließlich - die soetwas gar nicht brauchen. aber auf der anderen seite möchte man doch alles abdecken, und so auch für einsteiger diese hürde nehmen, die wie ich finde bisher zu recht kritisiert wurde. nicht jeder kann mit debian "umgehen" und in den genuss von apt-get kommen, apt-get als standard für andere distris fände ich also gar nicht sp verkehrt...

btw: programmiert habe ich nichts, was du siehst/liest ist
a) das konzept und
b) etwas zusammengegimptes

;)

[Freekazonid]

wenns denn klappt. ich kenne zwar selber kein apt-get, hab aber gelesen dass es auch damit probleme geben soll - unter einigen umständen.
ich hab urpmi eingesetzt und bin - neben dem eigentlichen komfort - auch an diverse probleme gewöhnt, wo sich pakete gegenseitig im weg standen, eben weil abhängigkeiten störten. meinst du ich aktualisier ein 5mb-programm, wo ich erst 300mb installieren muss? ich finde das nicht sehr elegant oder gar komfortabel!


also apt habe ich bisher noch nicht genutzt, kann darueber nicht sehr viel sagen, aber es hat doch einen excellenten ruf, bestimmt nicht umsonst. das apt viel probleme macht glaub ich nicht.

das mit dem 5mb programm upgraden: nagut, so extrem ist das nicht auch wenn ein fuenkchen wahrheit drann ist. ich wuerde das aber nicht als nach-, sondern als vorteil sehen, da nicht alle libs fix drinnen sind und das programm aus den sourcen neu gebaut wird; ich kann das begruessen. und was-wie-wo-wieso braucht ist mir auch egal, ein emerge -u oder ein apt-get -upgrade oder was es da gibt, etc, dann warten und fertig ist die sache ohne was zu machen - das meine ich mit sehr bequem




ganz einfach: die sourcen zu kompilieren ist für anwender meist eine ziemliche zwickmühle, nicht selten kommt es zu diversen problemen, und nicht zuletzt wegen den nicht aufzulösenden abhängigkeiten. das führt zum unnötigen spießroutenlauf, und das nicht zu selten. dabei geht jede menge zeit drauf, so dass man sich schnell fragt, ob's dass sein kann. ich weiß nicht ob es da anderen anfängern anders geht, ich jedenfalls war ohne urpmi ziemlich aufgeschmissen und kann behaupten, dass ich nur durch einen gewissen grad an masochismus und v.a.D. viel geduld am ball geblieben bin. das kann man leider nicht von vielen anderen neulingen behaupten :/
von den teilweise langen kompilierzeiten mal abgesehen.


also ich fand das immer sehr einfach, und hatte damals garkein packetmanagament tool gehabt. wenn ich programm X installieren wollte, und dsa zeigte A...Z als dependencies an, habe ich diese gesaugt installiert etc. oder wenn das zuviel wurde eben die sourcen gesaugt, was schnell einfacher&schneller war. aber das war auch nur die ausnahme

letztens habe ich zb ssh von meinem NAT geupdated, tar.gz gesaugt, entpackt make make install fertig war mein ssh geupdated, ohne irgendwelche dependencies schwierigkeiten oder so. das schaffen auch anfaenger, dazumal es rpm's gibt



glaub mir - beleidigt hast du mich damit in keinster weise. es gibt eben genug leute - mich einschließlich - die soetwas gar nicht brauchen. aber auf der anderen seite möchte man doch alles abdecken, und so auch für einsteiger diese hürde nehmen, die wie ich finde bisher zu recht kritisiert wurde. nicht jeder kann mit debian "umgehen" und in den genuss von apt-get kommen, apt-get als standard für andere distris fände ich also gar nicht sp verkehrt...

btw: programmiert habe ich nichts, was du siehst/liest ist
a) das konzept und
b) etwas zusammengegimptes

naja apt ist ja nur ein packetmanagement unter vielen - ich liebe portage ;)

achso, hab wohl etwas zu grob ueberflogen, dachte das sei nun das programm

[Susu]

das soll eben genau der knackpunkt sein. es soll kein unterschied sein, was man installiert, und woher - es wird durch den fleischwolf gedreht und auf die distribution angepasst, ganz gleich welche version oder welches paketsystem angewandt wird. warum tausende von gb verschwenden, nur weil ein suse-rpm nicht unter redhat läuft usw.?Hey, das Zitat, auf das Du Dich beziehst, ist gar nicht von mir...

Susu

[Susu]

nein, das hast du falsch verstanden. es bleiben die distributions-eigenheiten bestehen. nur die "oberfläche", die oberste schicht, wird vereinheitlich oder zumindest optional vereinfacht, für die "major" distributionen. um z.b. installationen per drag & drop zu gewährleisten. zumindest war das der ansatz, den ich mir so vorgestellt hatte.Naja, ich wüßte net, wozu ich das brauchen sollte. Echt nicht. Ich kenne wirklich viele Distris und mit jeder bin ich klar gekommen, auch was die Pakete betrifft. Ich WILL keine einheitliche Oberfläche für sowas. Außerdem würde diese "einheitliche Oberfläche" das Pakethandling IMHO noch viel komplizierter machen. Das einheitlichste, was es gibt, sind tarballs. Reicht das nicht?

Susu