Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Hey,
moje kluczowe pytanie, brzmi: Czy przejście z aptitude na apta będzie bezbolesne?
Dlaczego chcę przejść na apta?
Zainstalowałem u rodziców ubuntu 12.04LTS (w sumie to wyszło kubuntu). Mając nawyki debianowe po zainstalowaniu systemu podstawowego:
- ustawiłem
cat /etc/apt/apt.conf APT::Install-Recommends "false"; APT::Install-Suggests "false"; APT::AutoRemove::RecommendsImportant "false"; APT::AutoRemove::SuggestsImportant "false";
- zainstalowałem aptitude
- oraz czysty /root/.aptitude/config ustawiłem z odebranymi uprawnieniami.
Dalej wszystko instalowałem za pomocą aptitude głownie metapakietami. Wszystko śmiga.
Lecz nie pomyślałem, że moi rodzice sami nie poradzą sobie z aktualizacjami, a przede wszystkim z ewentualną instalacją nowych pakietów. Aktualizacji mógłbym ich nauczyć przy użyciu aptitude-gtk, lecz instalacja nowych, a przede wszystkim ich wyszukiwanie (a do tego chcę ich zachęcić) w wymienionym narzędziu dla nowicjusza, to już za wysoka poprzeczka.
Do KDE jest fajny menedżer pakietów muon oraz dodatki muon-notifier muon-updater muon-installer, a ich zależności są następujące:
~$ aptitude show muon Pakiet: muon Stan: zainstalowany Zainstalowany automatycznie: nie Wersja: 1.3.0-0ubuntu1 Priorytet: opcjonalny Sekcja: kde Opiekun: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> Rozmiar rozpakowanego: 508 k Wymaga: kde-runtime, libc6 (>= 2.3.4), libdebconf-kde0 (>= 0.1+git20101209), libkdecore5 (>= 4:4.3.4), libkdeui5 (>= 4:4.4.0), libkio5 (>= 4:4.3.4), libmuonprivate1, libqapt1 (>= 1.2.65), libqtcore4 (>= 4:4.8.0), libqtgui4 (>= 4:4.8.0), libstdc++6 (>= 4.1.1), libqapt-runtime, apt-xapian-index Poleca: muon-updater Opis: package manager for KDE Muon is a graphical package manager for KDE. Features of note include: * A powerful, yet intuitive interface * Fast, accurate package search using the apt-xapian index and the Synaptic search algorithm * Support for filtering packages by status and category * Media change support * Support for configuring packages through the debconf system * Warn about/disallow the installation of untrusted packages, depending on APT settings * Uses Polkit for running privileged actions for enhanced security, convenience, and desktop integration * Power management suspension during package downloads, installations and removals * Support for download the latest changelog of a package * Package screenshots Strona internetowa: https://projects.kde.org/projects/extragear/sysadmin/muon/
~$ aptitude show muon-notifier Pakiet: muon-notifier Stan: niezainstalowany Wersja: 1.3.0-0ubuntu1 Priorytet: opcjonalny Sekcja: kde Opiekun: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> Rozmiar rozpakowanego: 139 k Wymaga: libc6 (>= 2.1.3), libkdecore5 (>= 4:4.4.95), libkdeui5 (>= 4:4.4.0), libqt4-dbus (>= 4:4.5.3), libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>= 4:4.5.3), libstdc++6 (>= 4.1.1), muon-updater, update-manager-kde, update-notifier-common Opis: update notifier for KDE The Muon Notifier is an update notification daemon for KDE. It uses the KDE Daemon frame (KDED) framework to present the user with update notifications, providing an opportunity to launch the Muon Updater to deal with these updates. Strona internetowa: https://projects.kde.org/projects/extragear/sysadmin/muon/
~$ aptitude show muon-updater Pakiet: muon-updater Stan: zainstalowany Zainstalowany automatycznie: nie Wersja: 1.3.0-0ubuntu1 Priorytet: opcjonalny Sekcja: kde Opiekun: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> Rozmiar rozpakowanego: 217 k Wymaga: kde-runtime, libc6 (>= 2.3.4), libkdecore5 (>= 4:4.3.4), libkdeui5 (>= 4:4.6.80), libkio5 (>= 4:4.3.4), libmuonprivate1, libqapt1 (>= 1.2.80), libqtcore4 (>= 4:4.7.0~beta2), libqtgui4 (>= 4:4.5.3), libsolid4 (>= 4:4.3.4), libstdc++6 (>= 4.1.1), libqapt-runtime Poleca: muon-notifier Opis: update manager for KDE Muon Updater is a graphical update manager for KDE. It is part of the Muon family of software and provides an interface similar to that of Muon. Strona internetowa: https://projects.kde.org/projects/extragear/sysadmin/muon/
~$ aptitude show muon-installer Pakiet: muon-installer Stan: niezainstalowany Wersja: 1.3.0-0ubuntu1 Priorytet: opcjonalny Sekcja: kde Opiekun: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> Rozmiar rozpakowanego: 434 k Wymaga: kde-runtime, libc6 (>= 2.3.4), libdebconf-kde0 (>= 0.1+git20101209), libkdecore5 (>= 4:4.3.4), libkdeui5 (>= 4:4.6.80), libkio5 (>= 4:4.4.0), libmuonprivate1, libqapt1 (>= 1.2.65), libqjson0 (>= 0.7.1), libqt4-declarative (>= 4:4.7.0~rc1), libqt4-xml (>= 4:4.5.3), libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>= 4:4.8.0), libstdc++6 (>= 4.1.1), libqapt-runtime, app-install-data, apt-xapian-index Poleca: app-install-data-partner Opis: Utility for browsing, installing, and removing applications The Muon Software Center lets you browse and install thousands of applications available for Ubuntu. You can view available applications by category, or search quickly by name or description. You can also examine the applications already installed, and remove those you no longer need. To install or remove software using the Center, you need administrator access on the computer. Strona internetowa: https://projects.kde.org/projects/extragear/sysadmin/muon/
Moje kluczowe pytanie, brzmi: Czy przejście z aptitude na apta będzie bezbolesne?
Offline
Tak.
Offline
Dzięki za szybką odpowiedź. Przy okazji: jak wygląda obecnie "mieszanie" aptitude z aptem?
Offline
ja okazjonalnie mieszam jedno i drugie (jak któreś magicznie nie chce zaprądzić, ale głównie apta)
nie widze zadnych problemów jak dotąd
Offline
Może na wstępie: stwierdzenie „z aptitude na apta” trochę wprowadza w błąd. APT to system zarządzania pakietami z którego można korzystać za pomocą programów apt-get oraz aptitude (i innych), oraz przez nakładki na te programy. Odnośnie mieszania apt-get z aptitude: nie widzę żadnego istotnego powodu przeciwko. Co jednak nie znaczy, że takiego nie ma… Jeśli ktoś jakiś zna, też chętnie się dowiem.
Offline
ArnVaker napisał(-a):
Może na wstępie: stwierdzenie „z aptitude na apta” trochę wprowadza w błąd...
Fakt, nieprecyzyjne. Napisałem tak, bo nie wiem czy muon wywołuje apt-get, czy też działa inaczej. Nie mam pojęcia jak, ale jak ktoś wie, to niech podzieli się wiedzą ;). W zależnościach muon fraza apt występuje tylko raz, a konkretnie w apt-xapian-index
Ostatnio edytowany przez caViator (2012-03-18 22:23:37)
Offline
Ogólnie korzystam z apt-get, jednak zdarzają się "wpadki", że apt czegoś nie może, a aptitude robi i vice versa (ech, ten Linux :P). W dawnych czasach Aptitude pobierał o wiele więcej pakietów niż było potrzebne, nie wiem jak teraz
Fervi
Offline
Najszybciej chyba byłoby dać:
mv /usr/bin/apt-get /usr/bin/apt-get.old
I sprawdzić czy muon jeszcze działa. :) Też nie wiem, nigdy tego nie używałem.
EDIT: O, synaptic działa bez apt-get. Zawsze myślałem, że nie. ;)
Offline
na virtualboksie zainstalowałem sobie kde 4.7 weszło do wheezy
pojawił się Apper package manager dla kde
co o nim sądzicie ,
jak u was wygląda "mieszanie" Appera z aptitude i aptem?
Offline
ArnVaker napisał(-a):
Najszybciej chyba byłoby dać:
Kod:
mv /usr/bin/apt-get /usr/bin/apt-get.oldI sprawdzić czy muon jeszcze działa. :) Też nie wiem, nigdy tego nie używałem.
EDIT: O, synaptic działa bez apt-get. Zawsze myślałem, że nie. ;)
Dziś już jestem u siebie, ale jutro zalecę do rodziców i sprawdzę, choć pewnie jak synaptic działa, to i to samo będzie z muon :) Tu coś o nim piszą http://kdefamily.pl/index.php/aktualnoci/40-program … uon-suite-13-, ale mi to wiele nie mówi.
Offline
W sumie bardziej bym się obawiał tego muona w tym przypadku niż apt-get. Ale to dlatego, że nie wiem jak on się zachowuje i czy na przykład przy aktualizacji (albo usuwaniu czego innego) nie wywali jakichś przydatnych pakietów ponieważ zależności się zmieniły i nic już ich nie trzyma. Przy takich ustawieniach jak z pierwszego posta jest to możliwe, ale używając narzędzi z wiersza poleceń po prostu od razu widać takie rzeczy… Sam miałem już kiedyś locales i pciutils do odstrzału z tego powodu. W tej kwestii apt-get jest bezpieczniejszy niż aptitude, ponieważ sam nie wywala takich pakietów, a trzeba wywołać apt-get autoremove.
Offline
ArnVaker napisał(-a):
Jeśli ktoś jakiś zna, też chętnie się dowiem.
Czyż aptitude nie zapisuje sobie dodatkowych informacji podczas instalacji, usuwania pakietów? Czyż w takim razie po mieszaniu, aptitude — mając niepełne informacje — nie może zrobić czegoś inaczej niż normalnie powinien?
Osobiście stoję na stanowisku, że albo aptitude, ale pozostałe klienty APT-a (w uproszczeniu nazywane: apt-get i spółka).
Offline
azhag napisał(-a):
Czyż aptitude nie zapisuje sobie dodatkowych informacji podczas instalacji, usuwania pakietów? Czyż w takim razie po mieszaniu, aptitude — mając niepełne informacje — nie może zrobić czegoś inaczej niż normalnie powinien?
Coś zapisuje, ale nie mam pojęcia czy to się do czegokolwiek potem przydaje. W każdym razie statusy zainstalowany ręcznie/automatycznie działają normalnie przy mieszaniu apt-get z aptitude. Na pewno ma to znaczenie przy poleceniach specyficznych dla aptitude (jak np. forbid-version), ale nie zaliczyłbym tego do istotnych powodów. Zmieniając menedżera pakietów można sobie ten pakiet zatrzymać przez normalne hold czy w jeszcze inny sposób.
Offline
No i zapomniałem napisać za pierwszym razem: apt-get i aptitude zapisują log w innym pliku. Lepiej w razie czego badać jeden z nich, niż oba. ;)
Offline
AFAIK oba zapisują w tych samych + aptitude dodatkowo do /var/log/aptitude. Można jeszcze dorzucić, że aptitude da się skonfigurować w /root/.aptitude/config żeby zachowywał się inaczej niż apt-get. Ale to są takie głupoty IMO, chodziło raczej o to żeby coś zepsuć samym mieszaniem.
Offline
dpkg, apt-get, aptitude, synaptic, kynaptic, KPackage, Adept, PackageKit, Gdebi, gnome-apt, muon, apper.
Opanowanie tak podstawowego zadania jak instalacja programów ewidentnie sprawia deweloperom trudności, że wyprodukowali taką ilość narzędzi do tego celu. A im więcej ich produkują, tym większy czynią zamęt...
Ostatnio edytowany przez davidoski (2012-03-19 05:46:47)
Offline
davidoski, bo jeden lubi ogórki, a drugi ogrodnika córki ;P ja sam zamiennie korzystam z gdebi, aptitude, apt-get, synaptica i w skrajnych sytuacjach z dpkg :)
Offline
thomsson napisał(-a):
w skrajnych sytuacjach z dpkg :)
Wszystko co korzysta z APT-a (apt-get, aptitude itd.) do faktycznego instalowania/usuwania pakietów wywołuje dpkg.
Offline
caViator napisał(-a):
Przy okazji: jak wygląda obecnie "mieszanie" aptitude z aptem?
Wśród użytkowników Debiana pokutuje mit, że mieszanie aptitude i apt-geta prowadzi do kłopotów. Nikt nie wie jakich, nikt nie wie dlaczego, nikt nie wie skąd się ten pomysł wziął, ale na wszelki wypadek nikt nie próbuje mieszać.
davidoski napisał(-a):
dpkg, apt-get, aptitude, synaptic, kynaptic, KPackage, Adept, PackageKit, Gdebi, gnome-apt, muon, apper.
Opanowanie tak podstawowego zadania jak instalacja programów ewidentnie sprawia deweloperom trudności, że wyprodukowali taką ilość narzędzi do tego celu.
Nie do końca.
apt-get i aptitude są nakładkami na dpkg (nie wiem jak pozostałe, ale chyba też).
gdebi ma unikatową (przynajmniej do niedawna, może coś się zmieniło) zdolność instalowania pakietów lokalnych z automatycznym rozwiązywaniem ich zależności.
Niektórzy nie lubią mieszać aplikacji z różnych rodzin, więc jak jest program napisany przy użyciu GTK, to zwolennicy Qt chcą mieć jego funkcjonalny odpowiednik dobrze wpisujący się w ich pulpit.
Poza tym PackageKit, jest nakładką na kilka różnych menedżerów pakietów. Dodaje więc nową warstwę abstrakcji. Idea jest taka, że niezależnie od tego jakiej dystrybucji używasz, zawsze wykorzystujesz znane sobie narzędzie do zarządzania pakietami.
Ponadto kynaptic i Adept od lat nie są rozwijane, zaś Apper to nowsza wersja KPackageKit pod inną nazwą, który jest jedynie nakładką graficzną na PackageKit.
Z jednej strony masz rację, że narzędzi do zarządzania pakietami jest (zbyt?) dużo. Z drugiej — czy nie można tego samego powiedzieć o odtwarzaczach audio albo video, przeglądarkach obrazów, edytorach tekstu, programach pocztowych czy środowiskach graficznych? Jeżeli komuś nie odpowiadają istniejące rozwiązania jakiegoś problemu, tworzy własne. A dzięki wolnym licencjom wszyscy możemy z nich za darmo korzystać i wspomagać ich rozwój (jeśli potrafimy).
Offline
Minio napisał(-a):
Poza tym PackageKit, jest nakładką na kilka różnych menedżerów pakietów. Dodaje więc nową warstwę abstrakcji. Idea jest taka, że niezależnie od tego jakiej dystrybucji używasz, zawsze wykorzystujesz znane sobie narzędzie do zarządzania pakietami.
Ponadto kynaptic i Adept od lat nie są rozwijane, zaś Apper to nowsza wersja KPackageKit pod inną nazwą, który jest jedynie nakładką graficzną na PackageKit.
Dodam, że dla nas, Debianowców, PackageKit jest poza dyskusją, gdyż jego architektura nie całkiem współpracuje z architekturą pakietów .deb (cośtam z zależnościami, szczegółów nie pamiętam, bo i przesadnie mnie nie interesowały ;)). Przynajmniej do niedawna tak było.
Offline
Ten PackageKit: http://packages.qa.debian.org/p/packagekit.html? :)
Offline
a czy to nie jest tak, że od Squeeze oficjalnie rekomendowaną metodą było już aptitude zamiast apt-get?
osobiście używam aptitude ze względu na proponowanie rozwiązań w przypadku konfliktów.
Offline
Od Squeeze chyba właśnie apt-get. :D A przynajmniej przy aktualizacji Lenny → Squeeze.
Potato → Woody: dselect
http://www.debian.org/releases/woody/i386/release-n … selectupgrade
The recommended method for upgrading to Debian GNU/Linux 3.0 is using the package management tool dselect.
Woody → Sarge: aptitude
http://www.debian.org/releases/sarge/i386/release-n … adingpackages
The recommended tool for upgrading between Debian GNU/Linux releases is to use the package management tool aptitude.
Sarge → Etch: aptitude
http://www.debian.org/releases/etch/amd64/release-n … adingpackages
The recommended way to upgrade from previous Debian GNU/Linux releases is to use the package management tool aptitude.
Etch → Lenny: aptitude
http://www.debian.org/releases/lenny/amd64/release- … aptupgrade1st
Please note that using apt-get is not recommended for the upgrade from etch to lenny. If you do not have aptitude installed you are recommended to install it first.
Lenny → Squeeze: apt-get
http://www.debian.org/releases/squeeze/amd64/releas … pgrading-full
The upgrade process for other releases recommended the use of aptitude for the upgrade. This tool is not recommended for upgrades from lenny to squeeze.
=================
Natomiast oficjalnej informacji od deweloperów którego lepiej używać na co dzień chyba nigdzie nie widziałem.
Offline
ArnVaker napisał(-a):
Ten PackageKit: http://packages.qa.debian.org/p/packagekit.html? :)
Zapewne ten.
We wcześniejszym poście zjadłem "całkiem":
jego architektura nie całkiem współpracuje z architekturą pakietów .deb
Ogólnie przy okazji dyskusji o aptitude-qt i ogólnego narzekania, że nie ma żadnego menedżera pakietów w Qt było o ułomnościach KP z punktu widzenia ekosystemu Debiana: http://pusling.com/blog/?p=155 (+ komentarze; niestety i tu nie ma co konkretnie dolega KP)
Offline
Jakiś problem z obsługą debconfa chyba był, tutaj jest trochę na ten temat:
• http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468132
• http://dantti.wordpress.com/2010/08/23/debconf-support-on-kpackagekit/
(szczerze mówiąc nie chciało mi się tego czytać dokładnie ;))
Offline