So what happens if a package's postinst fails while packages that depend on the new version of it are still in the half installed state?rickh wrote:
Think about this. There is no equivalent in aptitude for apt-get's -f option? Why? That's easy. The need never arises.
Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Aptitude vs Apt-Get
If it doesn't finish, nothing is installed. As nearly as I've been able to observe, everything is just cleanly backed out.So what happens if a package's postinst fails while packages that depend on the new version of it are still in the half installed state?
Debian-Lenny/Sid 32/64
Desktop: Generic Core 2 Duo, EVGA 680i, Nvidia
Laptop: Generic Intel SIS/AC97
Desktop: Generic Core 2 Duo, EVGA 680i, Nvidia
Laptop: Generic Intel SIS/AC97
But there is an equivalent:rickh wrote:
Think about this. There is no equivalent in aptitude for apt-get's -f option? Why? That's easy. The need never arises.
Code: Select all
man aptitude
Code: Select all
-f Aggressively try to fix dependencies of broken packages.
Configuration Item: Aptitude::CmdLine::Fix-Broken
I've been using both apt-get & aptitude in combination for some time now and it works fine. I do have a fair amount of experience using apt tho and I wouldn't recommend it to new users. I do it like so
Code: Select all
alias ac="sudo aptitude clean"
alias au="sudo aptitude update"
alias aug="sudo aptitude upgrade"
alias as="aptitude search"
alias ash="aptitude show"
alias ai="sudo apt-get install"
alias dpl="dpkg -l|grep"
alias acp="apt-cache policy"
alias ar="sudo aptitude remove"
alias afi="sudo apt-get -f install"
alias dpi="sudo dpkg -i"
alias dif="sudo dpkg -i --force-overwrite"
alias acd="apt-cache depends"
alias ah="sudo aptitude hold"
I dislike the behavior of aptitude install & aptitude -f install so it's apt-get for those actions. Try it yourself and see the difference. There is no aptitude equivalent for apt-cache policy or dpkg -i --force-overwrite afaik and the last command I use alot on Sid.
Debian Sid Laptops:
AMD Athlon(tm) 64 X2 Dual-Core Processor TK-55 / 1.5G
Intel(R) Pentium(R) Dual CPU T2390 @ 1.86GHz / 3G
AMD Athlon(tm) 64 X2 Dual-Core Processor TK-55 / 1.5G
Intel(R) Pentium(R) Dual CPU T2390 @ 1.86GHz / 3G
Dang. I don't know how I missed that. I was looking for it once, too. At any rate, I've never been in a position that suggested it's use. I use aptitude exclusively on Sid, and have never had a single issue like that. Even installing difficult things like Cinelerra. Either the installation has worked, or if it failed due to dependency problems, I have just used aptitude to install the dependency and then it worked.Code: Select all
-f Aggressively try to fix dependencies of broken packages. Configuration Item: Aptitude::CmdLine::Fix-Broken
I am inclined to believe that all the issues related to mixing apt-get with aptitude have still not been worked out. I say, use aptitude exclusively, and it has not failed me yet.
That doesn't mean that other aspects of apt not useful. apt-cache policy is, of course, irreplaceable at this point. Depending on the specific need , I sometime use apt-cache search. apt-file, apt-show-version and others still roll easily off my fingertips, ... but apt-get is history.
Debian-Lenny/Sid 32/64
Desktop: Generic Core 2 Duo, EVGA 680i, Nvidia
Laptop: Generic Intel SIS/AC97
Desktop: Generic Core 2 Duo, EVGA 680i, Nvidia
Laptop: Generic Intel SIS/AC97
- txHarleyMan
- Posts: 366
- Joined: 2007-08-06 13:32
- Location: Texas
- craigevil
- Posts: 5391
- Joined: 2006-09-17 03:17
- Location: heaven
- Has thanked: 28 times
- Been thanked: 39 times
sidux Manuals - APT-Guide
Package managers like adept, aptitude, synaptic and kpackage are at the least, non-deterministic (for complex package selection), mix that with a quickly moving target like sid and even worse an external repository of questionable quality (we don't use or recommend those, but they're a reality on your user systems) and you will be courting disaster. The other item to note is that all of these types of GUI package managers need to run in init 5, and/or, in X, and in doing a dist-upgrade in init 5 and/or X , (or even an 'upgrade' which is not recommended), you will end up damaging up your system beyond repair, maybe not today or tomorrow, in time you will.
apt-get on the other hand strictly does what it is asked to do, if there is any breakage you can pinpoint and debug/ fix the cause, if apt-get wants to remove half of the system (due to library transitions) it's the admin's call (that means you) to have at least a serious look.
This is the reason why debian builds use apt-get, not the other package manager tools.
Raspberry PI 400 Distro: Raspberry Pi OS Base: Debian Sid Kernel: 5.15.69-v8+ aarch64 DE: MATE Ram 4GB
Debian - "If you can't apt install something, it isn't useful or doesn't exist"
My Giant Sources.list
Debian - "If you can't apt install something, it isn't useful or doesn't exist"
My Giant Sources.list
Code: Select all
dbnPC:/home/matt# aptitude install kate
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Writing extended state information... Done
Reading task descriptions... Done
Building tag database... Done
The following packages are unused and will be REMOVED:
libtagc0 thunar-media-tags-plugin xfce4-artwork xfce4-battery-plugin
xfce4-clipman-plugin xfce4-cpufreq-plugin xfce4-cpugraph-plugin
xfce4-diskperf-plugin xfce4-fsguard-plugin xfce4-genmon-plugin
xfce4-mailwatch-plugin xfce4-minicmd-plugin xfce4-mount-plugin
xfce4-netload-plugin xfce4-notes-plugin xfce4-quicklauncher-plugin
xfce4-screenshooter-plugin xfce4-sensors-plugin
xfce4-smartbookmark-plugin xfce4-systemload-plugin xfce4-verve-plugin
xfce4-wavelan-plugin xfce4-weather-plugin
The following NEW packages will be installed:
kate
The following packages are RECOMMENDED but will NOT be installed:
kregexpeditor
0 packages upgraded, 1 newly installed, 23 to remove and 0 not upgraded.
Need to get 0B/794kB of archives. After unpacking 3125kB will be freed.
Do you want to continue? [Y/n/?]
I do like that aptitude keeps a list of installed packages at /var/log/aptitude, does apt-get not do anything like that?
- Telemachus
- Posts: 4574
- Joined: 2006-12-25 15:53
- Been thanked: 2 times
I'm going to guess that at some point, you installed xfce4 as a metapackage. Then, later, you probably removed one component of the metapackage alone - using apt-get. A metapackage depends on all the individual items that it installs, so if you remove one, aptitude says, "Ok, now I will remove the metapackage itself and all the sub-packages that depend on it." There are ways to adjust the default behavior (which many people hate - it's the main dividing line between apt-get and aptitude users, so far as I can tell), but an easy way to solve your problem is to enter "aptitude keep-all" before you try to install kate with aptitude. Another way to look at it is this: aptitude and apt-get don't play entirely nicely together. Until now, I assume that you have been using apt-get. It's unfortunate, but normal to have troubles if you switch horses to aptitude without the keep-all comamnd. As far as I know, "aptitude keep-all" and then a steady diet of aptitude solves the problems - if you want aptitude that is. Another way to handle it is "apt-get install kate"actionM wrote:Why does aptitude want to uninstall things I use everyday?
Nope - hence this post here.actionM wrote:I do like that aptitude keeps a list of installed packages at /var/log/aptitude, does apt-get not do anything like that?
- Telemachus
- Posts: 4574
- Joined: 2006-12-25 15:53
- Been thanked: 2 times
I'm just curious: what does "Debian builds" mean in that sentence? (Maybe it's really obvious and I'm just slow today.) The reason I ask is that I thought that the current installers use Aptitude for items chosen in the tasksel section of installation. So I guess I'm wondering what "Debian builds" means if not installation.Craigevil (quoting the Sidux manual) wrote:This is the reason why debian builds use apt-get, not the other package manager tools.
I see references to Sidux all the time, but one should keep in mind that recommendations from the Sidux guys is for Sidux. Debian's official recommendation is Aptitude. Whether it will stay that way now that the new apt-get is out I guess we will not know until Lenny is released. But the bottom line is that it's very much a matter of taste and consistency. If you choose one and stick with it you should be fine. Mixing them might cause problems however.
As a side note: I just tried apt's new autoremove feature and it actually worked.
Tina
As a side note: I just tried apt's new autoremove feature and it actually worked.
Tina
This is exactly the reason I refuse to use aptitude install or aptitude -f install. The behavior is IMHO wrong.actionM wrote:
Why does aptitude want to uninstall things I use everyday?
I do like that aptitude keeps a list of installed packages at /var/log/aptitude, does apt-get not do anything like that?
As someone that has done all upgrades within X for several years I have to disagree but keep in mind that I use neither Gnome or KDE. I can't speak for what happens within those DE's. While I'm not going to recommend that anyone else do this, I do mix apt-get & aptitude and do it all in init 5. It has yet to fail me. I love the fact that my daily apt-get upgrades (never ever apt-get dist-upgrade) in Sid don't disturb my work routine in any way shape or form. I might restart X or compiz-fusion if they were updated.craigevil wrote:The other item to note is that all of these types of GUI package managers need to run in init 5, and/or, in X, and in doing a dist-upgrade in init 5 and/or X , (or even an 'upgrade' which is not recommended), you will end up damaging up your system beyond repair, maybe not today or tomorrow, in time you will.
BTW - aptitude does work fine in any runlevel - it does not require runlevel 5
Debian Sid Laptops:
AMD Athlon(tm) 64 X2 Dual-Core Processor TK-55 / 1.5G
Intel(R) Pentium(R) Dual CPU T2390 @ 1.86GHz / 3G
AMD Athlon(tm) 64 X2 Dual-Core Processor TK-55 / 1.5G
Intel(R) Pentium(R) Dual CPU T2390 @ 1.86GHz / 3G
- alleluia20
- Posts: 315
- Joined: 2006-11-21 21:27
Honestly, with the new apt which allows you to autoremove, I think that aptitude is dead.
As far as I know, the only extra "feature" that aptitude has right now is that you have to autoremove although you do not want to do so.
OK, aptitude has a log and apt does not have... But you can look at dpkg's logs
As far as I know, the only extra "feature" that aptitude has right now is that you have to autoremove although you do not want to do so.
OK, aptitude has a log and apt does not have... But you can look at dpkg's logs