Ich finde das sehr gut wenn es da endlich mal eine wirklich Dummy freundliche möglichkeit gibt Software zu instalieren. Wenn ich sehe wieviele verschiedenen RPM Versionen es manchmal von ein und dem selben Programm gibt, kann ich den Otto Normal User verstehen wen dieser behaubted das "Linux" Schwehr zu bedienen ist. Auch denke ich das es möglich sein muss Optionen mit auf den Weg zu geben. Sowas wie "Wollen sie ein Icon auf ihren Desktop". Oder aber eine Lizenzvereinbahrung anklicken. Ich weis Lizenzbedingungen werden manche hier verteufeln aber wen eine Firma eben Software nur mit einer Lizenz herausgibt soll es doch OK sein.
Wenn Autopackage funktioniert findet es bestimmt Zuspruch bei den Nutzern. Analog oder ISDN User haben keine günstige Möglichkeit ein Programm zu laden.Sie finden in einer Zeitschrift vielleicht genau das Programm das sie haben möchten, aber für eine andere Distri. Und der Versuch das Programm zu installieren führt meistens in Chaos. Bei Win geht es einfacher ein Programm zu installieren,aber das ist auch eine Schwachstelle , nicht umsonst gibt es Uninstaller in grosser Zahl.Fast unlösbare Probleme wird ein solches Programm auch mit verschiedenen Kernelversion und Kernelpatches bekommen.Aber es bleibt die Hoffnung das es funktioniert.
eigentlich müsste man die Distributoren zusammenbringen oder gleich das format in KDe integrieren, zum Freedesktop standard machen, damit es sich distriübergreifend durchsetzt.
Ja, aber das kapieren die nicht. Jeder Distributor soll doch weiterhin seine Vertriebskanäle und seine Icons benutzen dürfen, nur die Programme müssen auf jeder Distribution gleich installierbar sein, das ist af jeden Fall möglich. Trotzdem kann es dann immer noch genug Konfigurationsmöglichkeiten geben für individuelle Einstellungen.
Da gibt es nichts zu kapieren, "Vereinigung" kann man bei freier Software nicht erzwingen, denn gerade eine der Freiheiten ist es ja, dass jeder andere Wege gehen kann, die er fuer sinnvoller haellt. Die daraus resultierenden Probleme (Inkompatibilitaeten) muss man auf anderem Wege loesen, entweder durch Standards oder durch intelligente Loesungen wie Autopackage. So bewahrt man die Vielfallt und kommt trotzdem gut miteinander aus.
Und was ist es, wenn jeder Distributor KDE integriert? Das ist doch eine Art der (Ver)Einigung. Warum dann nicht sich sofort verständigen, wie es gemeinsam geht. Das ist doch der Sinn der Entwicklungsgruppen. Es besteht dann immer noch genügend Spielraum für individuelle Einstelungen. Außerdem kann man dann die freigewordenen Ressorcen für wichtigere Dinge einsetzen, als ob ich jetzt das Filesystem so der so gestalte der Endeffekt bleibt eh derselbe.
Ein einheitliches Paketformat alleine bringt auch noch nicht viel. RedHat, SuSE und Mandrake verwenden z.B. alle RPMs, trotzdem hat jede Distri ihre eignen RPMs. Eine Standartdistribution waere da die einzige Loesung.
Lesen und Verstehen. Genau deshalb wird doch autopackage entwickelt! Eine Standard(!)-Distribution (die übrigens nicht durchsetzbar wäre) wäre hingegen der Tod für Linux - oder meinst du sowas wie die LSB?
Ist es überhaupt sinvoll ein einheitliches Package System zu erfinden? Klar, von der komerziellen Seite her wäre das wichtig, aber irgendwie ist dies doch das einzige, was die Distributionen voneinander unterscheidet. Man sollte möglichst versuchen die Anzahl klein zu halten. Aber solange es verschiedene Distributionen gibt, wird es verschiedene Package Systeme geben. Zudem, so lange die Leute sich nicht auf ein einheitliches /etc einigen oder dieses ersetzen können, wird wohl nichts mit dem Einheitsbrei.
Von BufferOverflow am Mo, 8. September 2003 um 11:00 #
Nein, kein Punkt.
Er hat naemlich uebersehen, dass es nicht darum geht, aus allen Distributionen eineiige Zwillinge zu machen, sondern darum, dass ein Paketinstaller her muss, der auch die Umgebung prueft - das macht bisher naemlich keiner.
Bis dahin bleibt wohl nur ./configure, make, make install der systemuebergreifende "Installer".
Binärkompatibilität IST ein Problem. Wenn der Programmautor nicht unbedingt eine gcc2.95, gcc3.0, gcc3.1 und gcc3.2 Version kompiliert und alle in ein Paket packt, gibt es Probleme. Mindestens bei c++ Programmen, aber auch, wenn beim Paketersteller z.b. die glibc2.3 läuft, beim Endnutzer aber 2.2.
Von BufferOverflow am Mo, 8. September 2003 um 12:49 #
gcc 3.0 und 3.1 sind obsolet, wer nutzt denn bitte diese beiden Versionen?
2.95 kann ich so grad noch verstehen, obwohl mittlerweile der Grossteil (alle?) Distros 3.2 einsetzen.
Das mit glibc ist nen ganz einfach zu loesendes Problem, da es keine 20 Versionen davon gibt. Schau Dir mal andere Betriebssysteme an, z.B. Windows. Gibt es da EINE Version fuer ALLE? Auch nicht, dort wird auch zwischen 98/ME,NT und 2k/XP unterschieden.
Ach, dann ist der DLL-Wahnsinn nur eine üble Nachrede? An sich binärkompatible DLL's übers ganz offizielle Update haben plötzlich ein nicht-funktionieren von ACPI zur Folge. Man suche in den einschlägigen Foren wer dahingehend noch keine Erfahrungen gesammelt hat.
Also in Debian bin ich mit dem Hauseigenem System zufrieden ich brauch kein autopackage, bis jetzt . Es mag aber sein das es eine Alternative für kleine Distributionen ist oder auch Paketbetreuern, die ihre eigenen Pakete für möglichst viele Distributionen anbieten möchten, ein Werkzeug in die Hände gibt mit dem man einfach zum Ziel kommt ohne jeder Distribution sowie extra noch deren Revisionen ein eigenes Paket zur Verfügung zu stellen .
Man wird sicher erst nach Version 0.5 sehen ob es für eine Distribution taugt wie zum Beispiel Debian. Und bis dahin gibt es "alien". :-)
Es gibt nur 2 Möglichkeiten Linux für Benutzer mit geringer Systemkänntniss einfacher zu machen.
1 - Verzeichnisstruktur standardisieren, damit bei jeder Distrie z.B Kde im gleichen Ordner liegt. Alle Packete so bauen, dass bei erfüllten Packetabhängikeit das Packet normal installiert wird und bei nicht erfüllter packetabhängikeit, wird eine statisch kompilierte version von dem Programm installiert.
2 - eine Standardbibliothek erstellen die bei jeder Linuxdistrie gleich ist und jedes Packet kann mit dieser lib Sammlung problemlos installiert werden. Alle neueren libs müssen abwärtskompatiebel sein.
1. Grauenhaft. Wenn ich ein System haben will was mir vorschreibt was wo zu liegen hat kann ich ja auch gleich Windows nehmen. Und im Zweifelsfall statisch gelinkte Binaries? Stelle ich mir bei großen Paketen grauenhaft vor. Vor allem, wenn einzelne Komponenten von verschiedenen Paketen genutzt werden. Das gibt dann schöne, hausgemachte Inkompatibilitäten.
2. Das versuchen die in Redmond schon seit Jahren, allerdings ziemlich erfolglos.
3. Du hast die dritte, einfachste und beste Möglichkeit vergessen: Die Systemkenntnis des Benutzers verbessern/erweitern.
<Die Systemkenntnis des Benutzers verbessern/erweitern
Das geht leider am wenigsten. Du kennst dich ja auch nicht mit allem aus was du in deinem Leben benutzt. Wen ich meiner Mutter einen von Systemadminitrierern erzähle???
Daheim: Sysadmin muß Packete installieren können, und es soll funktionieren. In der Firma: Sysadmin muß Packete nicht nur installieren, sondern Performance Vergleiche machen, Systeme sichern (gegen außen und innen), usw.
Ergo nur weil jemand SuSE installieren und dann den Mozilla aktualisieren kann, heißt das nicht, das man ihn eine Firma inkl. VPNs, mehreren Servern usw. administriren lassen will.
Von Papa Schlumpf am Mo, 8. September 2003 um 08:46 #
Ad 1) Man könnte ja diverse Pfade in eine Konfig-Datei schreiben. KDE braucht beispielsweise sowieso environment-Variablen KDEDIR[S], KDEHOME, etc, da kann ja den KDE-Installations-Pfad auch in ein Konfig-file des Paketmanagers schreiben, und als Variable für Install-Scripte zur Verfügung stellen. Dann ists egal, ob kde in /usr, /usr/kde, /opt/kde oder sonstwo installiert wird, die Variable zeigt immer auf den aktuellen KDE. Analog bei GNOME, Staroffice/Openoffice und was auch immer. Normale 0815-Programme sollten aber immer in /usr/ kommen, denn die PATH-Variable kann auch nicht beliebig gross werden.
Ad 2) Man könnte meinen, das ist aus Marketinggründen so gewollt ...
Ad 3) Wär sicher der beste Ansatz, aber ie Lernresistenz und Ignoranz kombiniert mit der angeboreren Dummheit mancher Benützer scheinen das leider zur "Mission Impossible " werden zu lassen. Und die die lernwillig sind, kommen auch mit dem bisher vorhandenen zurecht, manchmal dauerts halt ein wenig länger.
Von BufferOverflow am Mo, 8. September 2003 um 11:06 #
> Leider haben sie es noch nicht bis zur regestrier datenbank geschafft.
Leider? Was bitte soll an der Registry so toll sein? Wenn es um Programmeinstellungen geht - okay, aber wenn man manchmal nur noch in die registry eingreifen kann, um Windows irgendeine Einstellung zu geben, dann ist das krank.
Und vor allem trauen sich soviele "Windowser" da auch dran.
Novell hatte mal ein Ding das nannte sich Bindary oder so ähnlich. Hatte so ein paar richtig coole Schwächen, im Prinzip wie bei der Registry. Dann hat Novell das Ding abgeschafft. Microsoft kam, und führe die Registry ein. Nach Jahren des Ärgers hört man tatsächlich, daß die Registry nicht wirklich toll ist und man sich was neues überlegt...
>> Leider haben sie es noch nicht bis zur regestrier datenbank geschafft. <<
Was heisst hier leider? Gottseidank! Ich möchte die Möglichkeiten alle Config-Files als Plain-Text zu haben und mit beliebigen Shell-Tools beackern zu können nicht mehr missen. Wenn ich unsere Windows-Admins so sehe dann wären die froh sowas machen zu können.
Von Thorsten Schnebeck am Mo, 8. September 2003 um 00:23 #
Letztlich muss es ein System geben, dass distributionsunabhängig Programme installiert und deinstalliert, ohne dass ein weiteres Paketverwaltungsprogramm benötigt wird. Wichtig ist auch, dass Pakete alle Abhängigkeiten selbst erfüllen können. Ganz wichtig dabei: Das muss klappen ohnes Nachfragen einfach mit einem Klick auf eine Install-Datei. Ebenfalls selbstverständlich heutzutage ist eine Paketsignatur, der man wahlweise vertrauen muss oder die bei bestehender Internetverbindung die Paketintegrität gewährleistet.
Das ideale System, was dem Anwender alle Arbeit abnimmt, setzt vorraus das im Hintergrund jemand anderes die entsprechenden Vorarbeiten macht (Abhängigkeiten, etc.). Genau das tun die Distributoren. Eine alles erschlagende Lösung wird es wohl aufgrund der Unterschiedlichkeit der Distributionen nie geben. Und IMHO sollte man die Vielseitigkeit voin Linux nicht aufgeben nur um eine einheitliche, deppensichere Installation zu erreichen.
Von Thorsten Schnebeck am Mo, 8. September 2003 um 08:23 #
Ich sehe keinen Vorteil in der der variantenreichen Installation von Applikationen. Auf Systemebene ist das was anderes. Mag jeder Hersteller sein eigenes Süppchen kochen was Grundinstallation und Systemverwaltung angeht, aber das Installieren von simplen Applikationen und Treibern sollte analog zu einer install.exe geschehen. [Meine Meinung]
Genau das ist Autopackage... Das mit dem Klick auf die Install Datei funktioniert per Default nicht, aber sobald du das erste Package File ausfuehrst funktioniert es danach auch mit weiteren package Files (also direkt per Klick), Distributionen koennten das natuerlich direkt so einrichten. Ich empfehle einfach mal die Foobar Testpakete runterzuladen und auszufuehren (foobar benoetigt foobar-core), das ist schon sehr beeindruckend. Dieses Visual LDD habe ich mir damit testweise installiert und das ging wirklich genau so: File anklicken, im Browser auf "Open" klicken, einmal auf "Ok" klicken, fertig. Funktioniert. Genau so stelle ich mir das vor. Was noch fehlt ist natuerlich das Netzwerk um evtl. benoetigte Pakete automatisch zu installieren, aber das kommt spaeter. Die Probleme mit Binaerkompatibilitaet, etc sind IMO ueberbewertet. Es gibt schliesslich auch etliche andere grosse Projekte die distributions-unabhaengige Binaries releasen, z.B. Mozilla oder OpenOffice.org. Autopackage stellt einfach ein Framework da um es Software Entwicklern zu ermoeglichen solche portablen Binaerpakete distributionsunabhaengig zu erstellen (nicht jeder kann seine Software unter 20 Distributionen testen) und das in einer sehr einfachen und komfortablen Art und Weise. Leichter als Autopackage kann Software-Installation wirklich nicht sein. Man muss nichtmal das root Passwort haben, da man es auch in den eigenen Home Ordner installieren kann. Fuer die "komplizierteren" Sachen wie z.B. das Grundsystem mit Desktop, System-Libraries, etc ist das erstmal gar nicht gedacht, sondern fuer optionale Anwendungen. Ideal waere das fuer Software wie Mozilla, OO.o oder Linux Spiele (der Loki Installer ist schon reichlich angestaubt).
Es lohnt sich auf jeden Fall mal die Informationen auf der Website zu lesen, wenn man sich dafuer interessiert. Die scheinen auf einem sehr interessanten Weg zu sein.
"By the way, you can uninstall it all like this: package uninstall gaim autopackage-gtk autopackage"
Grafisch geht es natuerlich noch nicht, waere aber kein Problem sofern der Desktop die entsprechende Infrastruktur bereit stellt. Ein spezielles Deinstallations-Programm nur fuer Autopackage Pakete waere sicher auch moeglich, aber nicht sehr wuenschenswert. Ich glaube Windows loest es indem sich installierte Programm eintragen (in die Registry ;)) und die entsprechende Deinstallationsart bestimmen koennen, so dass Windows dann eine Liste aller installierter Programme anzeigen kann die per Klick deinstalliert werden koennen. Das erscheint mir durchaus sinnvoll und sollte IMO auch trennen zwischen dem "Basissystem" (Libraries, Desktop, etc) und optionalen Anwendungen. Fuer Ersteres ist rpm, red-carpet, etc wahrscheinlich eh besser geeignet.
Als BSD- und Gentoo-Anwender kann ich diese Probleme garnicht nachvollziehen... Ich habe seit Jahren kein .deb oder .rpm mehr angefasst - dank der ports collection bzw. portage.
Und wenn der Weg wirklich zu einer sinnvollen Erweiterung gehen sollte, dann m.E.n. in der Art, das .rpm/.deb/.sonstwas von einem Tool wie autopackage nicht nach eigenem Gutdünken dort landet wo es will (Stichwort /opt/local vs /usr/local vs /usr/X11R6 vs ...), sondern dort, wo man seine GNUstow Datenbank hat, in der das ganze Userland landet - fein und sauber paketiert und archiviert.
nur das die ports collection sehr viel speicher brauch und nicht wirklich auf nem serversystem zu gebrauchen ist. ausserdem ist es dem anwender nicht wirklich zuzumuten gerade ebend mal bissel zu compilen - du musst mal davon ausgehen das in zukunft ein paar duemmere als du und ich linux benutzen wollen/sollen/muessen ... naja ok die koennen auch macosx benutzen ;) mfg olli
Ich benutze neben linux auch FreeBSD Die Protsammlung ist für eine Unerfahrenen User viel schwieriger als die installation eines RPM-Packets. Wenn die Ports über eine GUI sich updaten, installieren und deinstallieren liesen, wäre das für User mit DSL-Verbindung und schnellen CPU auch Akzeptabel. Vorausgesezt die Portsammlung hat keine Fehler. Was bei 9000 Ports unmöglich ist.
Von Papa Schlumpf am Mo, 8. September 2003 um 08:58 #
Warum nicht sowas erfinden? Einen Standard, der eine für Installationsskripte verbindliches API definiert (und damit ein für alle Distributionen einheitliches Paketformat), und als "low level driver" rpm/deb/ebuild/slp/tgz/was auch immer verwendet. Per Mapping table werden dann diverse Eigenheiten in der Paketnamensgebung berücksichtigt, und der Distributor hat immer noch die Möglichkeit, eigene kleine "Supperl" zu kochen.
Beim Installieren wird dann das neue Format durch ein Filter "gepiped", das dann am Ende ein .rpm file oder .deb-file ausspuckt und gleich installiert werden kann.
Ein Standard-Format für alle Distris ohne eine der Distris "Ihr" Format oder ihre eigenen Extrawürste zu verderben. Das wärs!
Auch denke ich das es möglich sein muss Optionen mit auf den Weg zu geben. Sowas wie "Wollen sie ein Icon auf ihren Desktop". Oder aber eine Lizenzvereinbahrung anklicken. Ich weis Lizenzbedingungen werden manche hier verteufeln aber wen eine Firma eben Software nur mit einer Lizenz herausgibt soll es doch OK sein.
Bei Win geht es einfacher ein Programm zu installieren,aber das ist auch eine Schwachstelle , nicht umsonst gibt es Uninstaller in grosser Zahl.Fast unlösbare Probleme wird ein solches Programm auch mit verschiedenen Kernelversion und Kernelpatches bekommen.Aber es bleibt die Hoffnung das es funktioniert.
So bewahrt man die Vielfallt und kommt trotzdem gut miteinander aus.
auch noch nicht viel.
RedHat, SuSE und Mandrake verwenden
z.B. alle RPMs, trotzdem hat jede Distri ihre
eignen RPMs.
Eine Standartdistribution waere da die
einzige Loesung.
du sowas wie die LSB?
Er hat naemlich uebersehen, dass es nicht darum geht, aus allen Distributionen eineiige Zwillinge zu machen, sondern darum, dass ein Paketinstaller her muss, der auch die Umgebung prueft - das macht bisher naemlich keiner.
Bis dahin bleibt wohl nur ./configure, make, make install der systemuebergreifende "Installer".
Gruss
Gruss
2.95 kann ich so grad noch verstehen, obwohl mittlerweile der Grossteil (alle?) Distros 3.2 einsetzen.
Das mit glibc ist nen ganz einfach zu loesendes Problem, da es keine 20 Versionen davon gibt.
Schau Dir mal andere Betriebssysteme an, z.B. Windows. Gibt es da EINE Version fuer ALLE? Auch nicht, dort wird auch zwischen 98/ME,NT und 2k/XP unterschieden.
An sich binärkompatible DLL's übers ganz offizielle Update haben plötzlich ein nicht-funktionieren von ACPI zur Folge. Man suche in den einschlägigen Foren wer dahingehend noch keine Erfahrungen gesammelt hat.
PS: Das war jetzt pure Ironie
http://autopackage.org/faq.html
Man wird sicher erst nach Version 0.5 sehen ob es für eine Distribution taugt wie zum Beispiel Debian. Und bis dahin gibt es "alien". :-)
1 - Verzeichnisstruktur standardisieren, damit bei jeder Distrie z.B Kde im gleichen Ordner liegt. Alle Packete so bauen, dass bei erfüllten Packetabhängikeit das Packet normal installiert wird und bei nicht erfüllter packetabhängikeit, wird eine statisch kompilierte version von dem Programm installiert.
2 - eine Standardbibliothek erstellen die bei jeder Linuxdistrie gleich ist und jedes Packet kann mit dieser lib Sammlung problemlos installiert werden. Alle neueren libs müssen abwärtskompatiebel sein.
2. Das versuchen die in Redmond schon seit Jahren, allerdings ziemlich erfolglos.
3. Du hast die dritte, einfachste und beste Möglichkeit vergessen: Die Systemkenntnis des Benutzers verbessern/erweitern.
Das geht leider am wenigsten. Du kennst dich ja auch nicht mit allem aus was du in deinem Leben benutzt. Wen ich meiner Mutter einen von Systemadminitrierern erzähle???
Für
>Die Systemkenntnis des Benutzers verbessern/erweitern
Chef zum Root: "Ich muss leider ihr Gehalt halbieren! Das was sie können, können alle anderen auch!"
- Jens
Daheim: Sysadmin muß Packete installieren können, und es soll funktionieren.
In der Firma: Sysadmin muß Packete nicht nur installieren, sondern Performance Vergleiche machen, Systeme sichern (gegen außen und innen), usw.
Ergo nur weil jemand SuSE installieren und dann den Mozilla aktualisieren kann, heißt das nicht, das man ihn eine Firma inkl. VPNs, mehreren Servern usw. administriren lassen will.
Ad 2) Man könnte meinen, das ist aus Marketinggründen so gewollt ...
Ad 3) Wär sicher der beste Ansatz, aber ie Lernresistenz und Ignoranz kombiniert mit der angeboreren Dummheit mancher Benützer scheinen das leider zur "Mission Impossible " werden zu lassen. Und die die lernwillig sind, kommen auch mit dem bisher vorhandenen zurecht, manchmal dauerts halt ein wenig länger.
zu kommen .
Leider haben sie es noch nicht bis zur regestrier datenbank geschafft.
Leider? Was bitte soll an der Registry so toll sein? Wenn es um Programmeinstellungen geht - okay, aber wenn man manchmal nur noch in die registry eingreifen kann, um Windows irgendeine Einstellung zu geben, dann ist das krank.
Und vor allem trauen sich soviele "Windowser" da auch dran.
Was heisst hier leider? Gottseidank! Ich möchte die Möglichkeiten alle Config-Files als Plain-Text zu haben und mit beliebigen Shell-Tools beackern zu können nicht mehr missen. Wenn ich unsere Windows-Admins so sehe dann wären die froh sowas machen zu können.
Wichtig ist auch, dass Pakete alle Abhängigkeiten selbst erfüllen können.
Ganz wichtig dabei:
Das muss klappen ohnes Nachfragen einfach mit einem Klick auf eine Install-Datei.
Ebenfalls selbstverständlich heutzutage ist eine Paketsignatur, der man wahlweise vertrauen muss oder die bei bestehender Internetverbindung die Paketintegrität gewährleistet.
Bye
Thorsten
Bye
Thorsten
Ich empfehle einfach mal die Foobar Testpakete runterzuladen und auszufuehren (foobar benoetigt foobar-core), das ist schon sehr beeindruckend.
Dieses Visual LDD habe ich mir damit testweise installiert und das ging wirklich genau so: File anklicken, im Browser auf "Open" klicken, einmal auf "Ok" klicken, fertig. Funktioniert. Genau so stelle ich mir das vor. Was noch fehlt ist natuerlich das Netzwerk um evtl. benoetigte Pakete automatisch zu installieren, aber das kommt spaeter.
Die Probleme mit Binaerkompatibilitaet, etc sind IMO ueberbewertet. Es gibt schliesslich auch etliche andere grosse Projekte die distributions-unabhaengige Binaries releasen, z.B. Mozilla oder OpenOffice.org. Autopackage stellt einfach ein Framework da um es Software Entwicklern zu ermoeglichen solche portablen Binaerpakete distributionsunabhaengig zu erstellen (nicht jeder kann seine Software unter 20 Distributionen testen) und das in einer sehr einfachen und komfortablen Art und Weise. Leichter als Autopackage kann Software-Installation wirklich nicht sein. Man muss nichtmal das root Passwort haben, da man es auch in den eigenen Home Ordner installieren kann.
Fuer die "komplizierteren" Sachen wie z.B. das Grundsystem mit Desktop, System-Libraries, etc ist das erstmal gar nicht gedacht, sondern fuer optionale Anwendungen. Ideal waere das fuer Software wie Mozilla, OO.o oder Linux Spiele (der Loki Installer ist schon reichlich angestaubt).
Es lohnt sich auf jeden Fall mal die Informationen auf der Website zu lesen, wenn man sich dafuer interessiert. Die scheinen auf einem sehr interessanten Weg zu sein.
package uninstall gaim autopackage-gtk autopackage"
Grafisch geht es natuerlich noch nicht, waere aber kein Problem sofern der Desktop die entsprechende Infrastruktur bereit stellt. Ein spezielles Deinstallations-Programm nur fuer Autopackage Pakete waere sicher auch moeglich, aber nicht sehr wuenschenswert.
Ich glaube Windows loest es indem sich installierte Programm eintragen (in die Registry ;)) und die entsprechende Deinstallationsart bestimmen koennen, so dass Windows dann eine Liste aller installierter Programme anzeigen kann die per Klick deinstalliert werden koennen. Das erscheint mir durchaus sinnvoll und sollte IMO auch trennen zwischen dem "Basissystem" (Libraries, Desktop, etc) und optionalen Anwendungen. Fuer Ersteres ist rpm, red-carpet, etc wahrscheinlich eh besser geeignet.
Probleme garnicht nachvollziehen...
Ich habe seit Jahren kein .deb oder .rpm mehr
angefasst - dank der ports collection bzw.
portage.
Und wenn der Weg wirklich zu einer sinnvollen
Erweiterung gehen sollte, dann m.E.n. in der
Art, das .rpm/.deb/.sonstwas von einem Tool
wie autopackage nicht nach eigenem Gutdünken
dort landet wo es will (Stichwort /opt/local vs
/usr/local vs /usr/X11R6 vs ...), sondern
dort, wo man seine GNUstow Datenbank hat, in
der das ganze Userland landet - fein und sauber
paketiert und archiviert.
mfg
olli
Die Protsammlung ist für eine Unerfahrenen User viel schwieriger als die installation eines RPM-Packets.
Wenn die Ports über eine GUI sich updaten, installieren und deinstallieren liesen, wäre das für User mit DSL-Verbindung und schnellen CPU auch Akzeptabel.
Vorausgesezt die Portsammlung hat keine Fehler. Was bei 9000 Ports unmöglich ist.
Beim Installieren wird dann das neue Format durch ein Filter "gepiped", das dann am Ende ein .rpm file oder .deb-file ausspuckt und gleich installiert werden kann.
Ein Standard-Format für alle Distris ohne eine der Distris "Ihr" Format oder ihre eigenen Extrawürste zu verderben. Das wärs!