| Author |
Message |
|
|
 |
Post subject: do NOT use apt-get autoremove
 Posted: Jun 18, 2007 - 08:06 AM
|
|
Joined: Dec 02, 2006
Posts: 232
Status: Offline
|
|
autoremove is on crack,
its idea of un-used is in major error
in short
if a upgrade error offers it as a option, to solve a issue
DONT DO IT
this is part of the new apt,
its not going away soon |
Last edited by etorix on Dec 28, 2007 - 01:31 PM; edited 1 time in total
|
| |
|
|
|
 |
|
|
 |
Post subject:
Posted: Jun 19, 2007 - 01:17 PM
|
|
Joined: Jun 04, 2007
Posts: 173
Location: Erfurt (Germany)
Status: Offline
|
|
Hi,
when will it be fixed? Recently (sunday evening) I have used this function without any problems, but I am afraid about your post!  What's the exactly problem of --autoremove?
thx, regards,
Guido |
_________________
thx + regards, Guido
__
sidux (since Τάρταρος) -- latest-slh-stable-kernel -- KDE 3.5.9
Asus A7N8X -- AMD Athlon XP 2400+ -- 1024 MB RAM -- Nvidia GeForce 4 MX 4000
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jun 19, 2007 - 01:43 PM
|
|
Team Member
Joined: Nov 24, 2006
Posts: 2616
Location: berlin
Status: Offline
|
|
it will not be fixed for sidux. we dont want that function in apt for sidux.
in a test i did it said it would remove about 20 not needed xorg modules. fine.
but:
in the end it removed xorg totally.
similar happened to others, removing ssh besides others.
i hope that says all.
this stuff may work for stable and ubuntu, but not for sid.
greetz
devil |
_________________
>>we are sidux - resistance is futile - you will be assimilated<<
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jun 20, 2007 - 07:03 AM
|
|
Joined: Jun 04, 2007
Posts: 173
Location: Erfurt (Germany)
Status: Offline
|
|
Oh thx, I thought, it is a bug which can be fixed...
regards |
_________________
thx + regards, Guido
__
sidux (since Τάρταρος) -- latest-slh-stable-kernel -- KDE 3.5.9
Asus A7N8X -- AMD Athlon XP 2400+ -- 1024 MB RAM -- Nvidia GeForce 4 MX 4000
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 21, 2008 - 06:22 PM
|
|
Joined: Dec 01, 2007
Posts: 6
Location: Berlin, Germany
Status: Offline
|
|
Reading the list of what will be deleted should also work, or give deborphans a try.
HennR |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 22, 2008 - 01:50 AM
|
|
Joined: Nov 30, 2006
Posts: 3087
Location: Budapest
Status: Offline
|
|
| Not autoremove is on crack, those people who recommend it might be. Here:
Code:
# apt-get autoremove -s
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Reading state information... Fertig
Die folgenden Pakete werden ENTFERNT:
amarok-engines artsbuilder atlantik atlantikdesigner cli-common dcoprss dirmngr ed empty-expect fastjar ffmpeg2theora fping freeglut3 gcc-3.4-base gcj-4.1-base
gcj-4.3-base gnome-bin gnome-libs-data gnupg-agent gnupg2 gpgsm gstreamer0.10-gnomevfs gtk2-ex-formfactory-perl iputils-arping kaboodle kaddressbook-plugins kandy
karm kate-plugins kaudiocreator kcoloredit kdeaddons-kfile-plugins kdemultimedia-kappfinder-data kdemultimedia-kfile-plugins kdict kdnssd kdvi kfax kfaxview kgamma
kget kicker-applets kiconedit kleopatra kmailcvt kmid kmrml kolourpaint konq-plugins konsolekalendar kpf kpilot kpovmodeler krec kruler kscd ksig ksirc ktnef kview
kviewshell kwifimanager lapack3 libart2 libarts1-audiofile libarts1-mpeglib libarts1-xine libatk1.0-dev libavformatcvs51 libbcel-java libcapi20-3 libcdaudio1
libcdk5 libconvert-binhex-perl libcrypt-ssleay-perl libcwidget0 libcwidget1 libdb4.3 libdb4.6++ libelfg0 libexif-dev libexiv2-0 libfile-temp-perl
libfinance-quote-perl libg2c0 libgadu3 libgalago3 libgfortran2 libgl1-mesa-dev libglew1.4 libglib2.0-dev libglpk0 libgmime-2.0-2 libgnome-menu2
libgnome-window-settings1 libgnome32 libgnomesupport0 libgnomeui32 libgnorba27 libgnorbagtk0 libgphoto2-2-dev libgpod2 libgsmme1c2a libgtkhtml3.8-15
libhdf5-serial-1.6.5-0 libhtml-tableextract-perl libice-dev libindex0 libintl-perl libio-stringy-perl libiodbc2 libkdcraw1 libkdegames1 libkexiv2-1 libkgantt0
libkpathsea4 libksba8 liblockdev1 liblog4j1.2-java liblua5.1-0 libmeanwhile1 libmime-perl libmime-tools-perl libmtp5 libmtp6 libmx4j-java libmyspell3c2
libnautilus-extension1 libneon25 libneon26 libnews-nntpclient-perl libnl1 libnm-util0 libnss3-0d libntfs-3g16 libntfs-3g21 libntfs-3g23 libnucleo0 libopenspc0
libopensync0 liborbit0 libpci2 libpisock9 libpng12-dev libportaudio2 libqhull5 libqt0-ruby1.8 libregexp-java librplay3 libsm-dev libsmokeqt1 libsoup2.2-8
libstartup-notification0-dev libstring-shellquote-perl libstroke0 libsuitesparse libsvnqt3 libtotem-plparser1 libusb-dev libwv-1.2-3 libx11-dev libx264-56
libxau-dev libxcomposite-dev libxcursor-dev libxdamage-dev libxdmcp-dev libxext-dev libxfixes-dev libxinerama-dev libxrandr-dev libxrender-dev
linux-headers-2.6.24-1-common linux-headers-2.6.24-2.6.24.3.slh.5-common linux-headers-2.6.24-2.6.24.3.slh.5-sidux-686 linux-headers-2.6.24-2.6.24.3.slh.6-common
linux-headers-2.6.24-2.6.24.3.slh.6-sidux-686 linux-kbuild-2.6.22 lsdvd mesa-common-dev mpeglib networkstatus ocaml-base-nox ocaml-findlib ocaml-interp ocaml-nox
pkg-config prelink pyqt4-dev-tools python-ctypes python-qt4 python-qt4-common refblas3 soundkonverter tex-common texinfo texlive-base texlive-base-bin
texlive-common texlive-doc-base texlive-fonts-recommended type-handling vgabios vnc-common x11proto-composite-dev x11proto-core-dev x11proto-damage-dev
x11proto-fixes-dev x11proto-fonts-dev x11proto-input-dev x11proto-kb-dev x11proto-randr-dev x11proto-render-dev x11proto-xext-dev x11proto-xinerama-dev xtrans-dev
zlib1g-dev
0 aktualisiert, 0 neu installiert, 217 zu entfernen und 8 nicht aktualisiert.
Good laugh, thanks, next.
hubi |
_________________
Bonitas stultitiaque sodales sunt.
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 22, 2008 - 01:56 AM
|
|
Joined: Dec 02, 2006
Posts: 1802
Status: Offline
|
|
A laugh...not
Autoremove is brain dead and does not take into account Sid. So hubi's post is a good example of what can befall an unsuspecting user if autoremove's used. So that's a very good reason for devil to say this feature is not recommended nor supported for sidux. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 22, 2008 - 03:33 AM
|
|
Joined: Dec 01, 2006
Posts: 410
Location: San Antonio, TX
Status: Offline
|
|
I don't know what's so different about sidux but it works fine on my Debian Sid.
The only time it recommends removing something if (correctly I might add) if a dependency changes or I remove a package that left had dependencies no longer needed.
So while it might not be recommended for sidux, it definetely works here. It seems to work fine for most the users on the forum.debian that I frequent as well.
To understand why it may not always seem to recommend what seems like a sane choice, you need to understand the relationship of metapakages to those packages you have listed above.
Please don't assume that the Debian devs introduce brain dead features that do not take into account the distribution that packages must be built against. |
_________________
Debian Unstable
Linux Kernel 2.6.26
KDE 4.1.64 (KDE 4.2 >= 20080828)
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 22, 2008 - 05:46 AM
|
|
Joined: Nov 28, 2006
Posts: 4096
Status: Offline
|
|
Take a look at hubi's example. This is repeatable empirical evidence. Study it. Refrain from responding until your mind is able to see what he said without entering into a state of denial. I'm not sure why this simple demonstration always fails to convince people who want to believe that this feature is not seriously flawed.
The fact that this is repeatable on both sid and etch, in my tests as well, basically shows that there are problems in the configurations or something that are not being reliably handled. Maybe one day they will be, but they are not now, not consistently, not reliably.
When you type, totally ignoring what hubi posted, that 'The only time it recommends removing something...' while looking directly at a first person sample of it doing the exact opposite, you have to realize that there is a problem, and stop pretending that there isn't just because your case doesn't trigger the problem.
My tests confirmed hubi's results, there is a serious problem with something in auto-remove, as there is in aptitude, and it may very well be the same problem, I cannot say. I don't know what it is, but it's repeatable and easy to see once you look at negative examples instead of only positive ones.
I write code that works usually then someone has a problem with it, should I tell them that it's fine and that there's nothing wrong because it works fine for many users, including me, or should I look for the bug and admit there is a problem? That's not a real question, obviously, refusing to see or admit problems is how you maintain and perpetuate problems. And i assume this is why those particular problems still persist.
And the best way to find bugs and problems is take problem reports, negative cases, bug reports, very seriously. Not deny them because it doesn't fit with some belief or faith. Good software is improved by fixing issues, not by pretending they don't exist. So what is wrong with this stuff? Where is the problem? Why does it not perform as expected consistently, what triggers the issues, what triggers bad cases of removals, why do some not trigger?, etc. These are the correct questions to ask. And that's how the problems will get fixed. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 22, 2008 - 06:14 AM
|
|
Joined: Mar 16, 2008
Posts: 79
Status: Offline
|
|
AFAIK the autoremove feature does exactly what it was intended to do. If software works as it is intended then there is no bug regardless if someone dislikes how it works. It is a wishlist bug at best but since autoremove was specifically designed to rip things out I would expect a wishlist bug to be ignored as well.
I like the autoremove feature. You have to be careful with it since it does play hell with meta-packages(by design) and hunts down dependencies with a vengenance. I also think it may go after tasks as well. I am not sure how well it deals with holds and/or pinning either since I don't use either. But overall I like it. I see no problem to fix. You don't have to use it afterall. And AFAIK you can always tell it that you want to keep what is currently on your system regardless if it thinks it should be removed.
*** Just wanted to clarify - My statements apply to my experience with the autoremove feature on Debian testing/sid and not to sidux. If the sidux teams feels that it is bad to use autoremove on sidux then that is certainly their decision to make. If they say that autoremove should not be used in sidux then I would certainly believe them and not argue against what they suggest. Who else knows sidux better than the sidux devs  |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 22, 2008 - 06:38 AM
|
|
Joined: Dec 01, 2006
Posts: 716
Location: Germany
Status: Offline
|
|
|
|
|
|
|
|
|
Post subject:
Posted: Mar 22, 2008 - 06:45 AM
|
|
Joined: Nov 28, 2006
Posts: 4096
Status: Offline
|
|
Read the output, karm, kate-plugins here, etc... and not reading simple empirical data is of course why the bugs and lack of robustness never get fixed. Denial does not fix bugs, it's a very poor substitute for making code reliable and robust, and trustworthy. Software that works reliably only sometimes is not good software, it's software that is not done yet and needs a lot more work. It may evolve into good software, and that's of course to be hoped for, but not until someone decides to take problems more seriously, and not just say they aren't problems. thus not warranting fixing. That's easy, sure, I can do that too.... or I can fix my bugs and get on with it. or maybe admit I can't.....
I got similar results on a fresh etch install by the way, but I am not positive it's the same cause, since it was aptitude that insisted on removing almost all of my newly installed kde before I could install anything....
That's a bug, it's an error, it's not a wishlist item, and if the devs won't admit error, the bugs and problems will not get fixed. That's a very bad strategy for software development, but each to their own. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 22, 2008 - 07:28 AM
|
|
Joined: Mar 16, 2008
Posts: 79
Status: Offline
|
|
I am looking at the emperical data posted in this thread.So far it is consistant in its actions. So far it is reliable. Everyone has reported the same/similar results. Many do not like how it works though.
It is a great tool IF you are wanting to remove a package and dependencies, especially a meta-package or cleaning up after removing a task. If that isn't what you are wanting then don't use it.
Have you ever wanted to remove ALL of gnome from your system? How would you do it? You could apt-get remove gnome but what does it do? It removes one fake package and leaves everything else behind. How to fix that? It is simple now apt-get autoremove gnome
It is a tool that has a certain use. If it isn't what you are wanting then simply don't use it. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 22, 2008 - 08:26 AM
|
|
Joined: Feb 24, 2007
Posts: 652
Location: Berlin, Germany
Status: Offline
|
|
It is a dumb tool, that does see the world in black and white (ONLY). It works if you are experienced, careful and never use Metapackages (or like MeanDean just for experimenting). But if you ever forget which meta you did pull in, it ruins not just your day, but....
The simple rm -rf can do the same if executed in the wrong place. Also not supported in sidux!
cheers Micha |
_________________
http://sidux.com/PNphpBB2-viewtopic-t-2403.html
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Mar 22, 2008 - 11:34 AM
|
|
Joined: Nov 30, 2006
Posts: 3087
Location: Budapest
Status: Offline
|
|
|
JackieBrown wrote:
To understand why it may not always seem to recommend what seems like a sane choice, you need to understand the relationship of metapakages to those packages you have listed above.
This is a fairly new notebook and I installed eros pre1 which was just released when I baught it 4-5 months ago.
deborphan gives me a similar output. And it is not only maybe outdated stuff, there are kde packages in this list which I use every day like kget.
The sidux settings do not look very exciting:
Code:
root@philly:/etc/apt/apt.conf.d# cat 01autoremove
APT
{
NeverAutoRemove
{
"^linux-image.*";
"^linux-restricted-modules.*";
};
};
You say that Sid users happily use autoremove regularily, though this is the first hit in Google searching "autoremove site:forums.debian.net":
http://forums.debian.net/viewtopic.php?t=17501.
The solution offered there:
Quote:
apt's letting you know that automatically installed packages are no longer needed. If you really want to keep them(and don't want to ignore the message anymore), just C&P and tell apt-get to install them. It will set them to 'manually installed' and stop bugging you about them.
Seems to me to be joke part II.
If I really want to know if old packages are a danger, I do:
Code:
# apt-get install debsecan
$ debsecan --suite sid | grep orphaned
That gives me orphaned packages which have a security problem. This works very reliably.
hubi |
_________________
Bonitas stultitiaque sodales sunt.
|
| |
|
|
|
|
|
|
