Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
alien-aptosidOffline
Post subject:   PostPosted: 17.10.2010, 14:11



Joined: 2010-10-03
Posts: 24

Status: Offline
      OppaErich wrote:
That's why god created aliases. Wink


thanks OppaErich. may be better to do apt-get install aptitude Wink.A second reason for Aptitude search(even though slower) is because it give the additional flags (like i for installed etc)

If we need that info we will have to use dpkg after using apt.
 
 View user's profile Send private message  
Reply with quote Back to top
tqkOffline
Post subject:   PostPosted: 05.11.2010, 21:56



Joined: 2010-11-03
Posts: 14
Location: I'd go pretty much anywhere.
Status: Offline
      slam wrote:
      monkeynuts wrote:
I have yet to meet anyone that runs Testing or Sid that leaves the X to do upgrades....

Well, fine. This has nothing to do with aptosid, as we do not simply "upgrade", but always "dist-upgrade", and leave X to do so. And we do not use aptitude (which is not "the debian way", ...

I'm a long term debian guy, and generally watch debian-user & -mentors. There's lots of credible people in both swearing off aptitude & synaptix. After years of distilling it all down, "init3 ; apt-get dist-upgrade ; init 5" sounds the most sensible of upgrade methods I've seen. If your video card driver is part of what gets upgraded, you'll be lost using a GUI pkg mgr.

I've been running Linux since ca. '93. FWIW.
 
 View user's profile Send private message Visit poster's website Yahoo Messenger  
Reply with quote Back to top
cassieOffline
Post subject:   PostPosted: 04.05.2011, 03:00



Joined: 2011-03-18
Posts: 4

Status: Offline
I've heard a lot of people say that upgrading in X with synaptic can damage your system, but I've yet to hear anyone explain in detail, HOW it damages your system. Can someone give a step by step scenario, of what synaptic does to the system, that can't be recovered from?

Please also explain why it won't be fixed by booting in a liveCD, and doing the following:
      Code:

# mkdir /mnt/tmp
# mount /dev/sda1 /mnt/tmp
# chroot /mnt/tmp
# dpkg --configure -a
# apt-get update
# apt-get dist-upgrade
 
 View user's profile Send private message  
Reply with quote Back to top
devilOffline
Post subject:   PostPosted: 04.05.2011, 06:35



Joined: 2010-08-26
Posts: 491
Location: Berlin
Status: Offline
well, apt vs. aptitude is religion, as is kde vs. gnome.
using a gui like synaptic to do adiminstrative work seems generaly not a good idea to me.of course anyone may use what they like. i like to stay out ofd trouble and dont need wasting time on live cds in a chroot.

greetz
devil
 
 View user's profile Send private message  
Reply with quote Back to top
DonKultOffline
Post subject:   PostPosted: 04.05.2011, 07:56
Team Member


Joined: 2010-09-02
Posts: 481

Status: Offline
APT vs. aptitude is not a religion - as everybody knows APT is the only deity (of package managers - just look who answers if you mail deity@lists.debian.org) and you can't have other package managers beside your deity. Wink (seriously, i am just kidding - maybe Wink )

Sure you can fix everything, it just depends how complicated it is. It's not impossible that your system you want to chroot into is broken (in that case e.g. dpkg) so that it doesn't work. You can fix even that by using the dpkg of your live-cd with a hell lot of options (--rootdir as on of those) -- in the hope that you have a recent live-cd which doesn't have incompatible dpkg versions (and yes, that happens from time to time: e.g. introduction of triggers), but yeah, why exactly do you want to invest hours of valuable time to fix problems you could have avoided just by upgrading out of X…

And yes, a dying X isn't impossible in unstable. Or a crashing kdm or whatever environment you might or might not use - not to mention power loose or alike - which could cause a inconsistent system dpkg tries to avoid, but avoiding doesn't mean it is impossible to reach…

_________________
MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor
 
 View user's profile Send private message Visit poster's website  
Reply with quote Back to top
cassieOffline
Post subject:   PostPosted: 05.05.2011, 07:18



Joined: 2011-03-18
Posts: 4

Status: Offline
      DonKult wrote:
APT vs. aptitude is not a religion - as everybody knows APT is the only deity (of package managers - just look who answers if you mail deity@lists.debian.org) and you can't have other package managers beside your deity. Wink (seriously, i am just kidding - maybe Wink )

Sure you can fix everything, it just depends how complicated it is. It's not impossible that your system you want to chroot into is broken (in that case e.g. dpkg) so that it doesn't work. You can fix even that by using the dpkg of your live-cd with a hell lot of options (--rootdir as on of those) -- in the hope that you have a recent live-cd which doesn't have incompatible dpkg versions (and yes, that happens from time to time: e.g. introduction of triggers), but yeah, why exactly do you want to invest hours of valuable time to fix problems you could have avoided just by upgrading out of X…

And yes, a dying X isn't impossible in unstable. Or a crashing kdm or whatever environment you might or might not use - not to mention power loose or alike - which could cause a inconsistent system dpkg tries to avoid, but avoiding doesn't mean it is impossible to reach…


The point is, no one has shown me any evidence, that there is a problem to be avoided. So far I've seen nothing but to suggest that runlevel 3 is any safer than runlevel five. Some guru says you should != evidence.

The so called damage from running under X , could be just another urban myth, based on assumptions. If there is a real danger, I want to understand it, not just accept it as fact , because someone says so.
 
 View user's profile Send private message  
Reply with quote Back to top
devilOffline
Post subject:   PostPosted: 05.05.2011, 07:21



Joined: 2010-08-26
Posts: 491
Location: Berlin
Status: Offline
is it enough if i tell you, i have seen it happen that synaptic messed up? besides that i have trustworthy people telling me it happend to them.

greetz
devil
 
 View user's profile Send private message  
Reply with quote Back to top
DonKultOffline
Post subject:   PostPosted: 05.05.2011, 07:59
Team Member


Joined: 2010-09-02
Posts: 481

Status: Offline
      cassie wrote:
      DonKult wrote:
And yes, a dying X isn't impossible in unstable. Or a crashing kdm or whatever environment you might or might not use - not to mention power loose or alike - which could cause a inconsistent system dpkg tries to avoid, but avoiding doesn't mean it is impossible to reach…


The point is, no one has shown me any evidence, that there is a problem to be avoided. So far I've seen nothing but to suggest that runlevel 3 is any safer than runlevel five. Some guru says you should != evidence.


Uhm, what evidence do you want beside what i already said and you quoted? Should i take a screenshot next time X dies? You know that if X dies all applications relaying on it die, too? So what do you think happens with $graphical_packagemanager?

And its not even limited to that: Even if you run apt-get in a graphical console - this console can crash, too (Happens to me from time to time, so thats not a "a friend told me that a friend of him has a cat who had a similar yet completely different problem" situation).

But yeah, if you don't trust us feel free to don't follow our suggestions. We just want to make sure that you are not coming back here to ask for help in case you broke your system that way. Its that simple…

_________________
MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor
 
 View user's profile Send private message Visit poster's website  
Reply with quote Back to top
slamOffline
Post subject:   PostPosted: 05.05.2011, 10:49
Team Member


Joined: 1970-01-01
Posts: 607
Location: w3
Status: Offline
The serious reasons for why not dist-upgrading from within X running (or using synaptic, aptitude, etc.) are clearly explained in our manuals since ever, see http://manual.aptosid.com/en/sys-admin- ... pt-upgrade
Greetings,
Chris

_________________
an operating system must operate
development is life
my Debian repo
 
 View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number 
Reply with quote Back to top
cassieOffline
Post subject:   PostPosted: 06.05.2011, 01:00



Joined: 2011-03-18
Posts: 4

Status: Offline
      slam wrote:
The serious reasons for why not dist-upgrading from within X running (or using synaptic, aptitude, etc.) are clearly explained in our manuals since ever, see http://manual.aptosid.com/en/sys-admin- ... pt-upgrade
Greetings,
Chris


No they aren't, and even if they were, I'm not at all asking WHY, I shouldn't so upgrades in X or using synaptic. I'm asking, what exactly happens that causes the damage, when using them.

If you asked " what is the bio-chemical reaction that causes conception", would you accept "if you have sex without a condom you'll get pregnant " as an answer? The answers I've seen here are about that useful.
 
 View user's profile Send private message  
Reply with quote Back to top
aylaOffline
Post subject:   PostPosted: 06.05.2011, 03:19



Joined: 2010-09-11
Posts: 50
Location: Germany
Status: Offline
      cassie wrote:
I'm not at all asking WHY, I shouldn't so upgrades in X or using synaptic. I'm asking, what exactly happens that causes the damage, when using them.



I guess the only way to find out is setting up a test system and try out.
Then when it happened you may analize what happened.
And if you like to dig deeper after then you may like to review the source-code of apt vs. aptitude or synaptic.

If I've understood a few of the estimated 10000 answers DonKult and others have written to this object right one of the scenarios is -in small words because my understandings of this complicate matter are small:
1) You have a running X and do an upgrade which upgrades a lib or similar which is currently in use.
2) Because it is in use it cant be replaced with the current version.
3) Other components, which depend on the new version weren't in use and were updated.
4) So you have a mix of incompatible versions which will lead to a non functional X, or -worst case- a not running system anymore because some essential function has died for this reason. And because the X-system has a lot of dependencies the chance to run into this scenario is high.

Of course, if you are skilled enough, you may fix anything in chroot. But where is the point to take the risk?

Save way is: use synaptic for searching if you like it and apt to install.
And avoid d-u in X.
greets
ayla
 
 View user's profile Send private message  
Reply with quote Back to top
devilOffline
Post subject:   PostPosted: 06.05.2011, 05:29



Joined: 2010-08-26
Posts: 491
Location: Berlin
Status: Offline
the best i can say is, that, when doing testruns on synaptic a couple years back, everything worked fine if installing/purging just single packages.
synaptic made a real mess on 2 instances removing a bunch of packages, putting dpkg into an inconsistent state. if i would have not noticed before rebooting, i could have ended with an unbootable system. as i did notice, reconfiguring dpkg fixed it.

as to upgrading in X. its just good practice to leave X if packages from your DE (KDE, Gnome, XFCE...) are involved.

greetz
devil
 
 View user's profile Send private message  
Reply with quote Back to top
cassieOffline
Post subject:   PostPosted: 06.05.2011, 18:43



Joined: 2011-03-18
Posts: 4

Status: Offline
      ayla wrote:
      cassie wrote:
I'm not at all asking WHY, I shouldn't so upgrades in X or using synaptic. I'm asking, what exactly happens that causes the damage, when using them.



I guess the only way to find out is setting up a test system and try out.
Then when it happened you may analize what happened.
And if you like to dig deeper after then you may like to review the source-code of apt vs. aptitude or synaptic.

If I've understood a few of the estimated 10000 answers DonKult and others have written to this object right one of the scenarios is -in small words because my understandings of this complicate matter are small:
1) You have a running X and do an upgrade which upgrades a lib or similar which is currently in use.
2) Because it is in use it cant be replaced with the current version.
3) Other components, which depend on the new version weren't in use and were updated.
4) So you have a mix of incompatible versions which will lead to a non functional X, or -worst case- a not running system anymore because some essential function has died for this reason. And because the X-system has a lot of dependencies the chance to run into this scenario is high.

Of course, if you are skilled enough, you may fix anything in chroot. But where is the point to take the risk?

Save way is: use synaptic for searching if you like it and apt to install.
And avoid d-u in X.
greets
ayla


Thank you, this is the kind of answer I was looking for.
if this is entirely accurate, than not being in runlevel 3 would be a problem. The question is whether point #2 actually true. Does being in use in fact prevent the package manager from updating it? My understanding up until now is that it doesn't.
 
 View user's profile Send private message  
Reply with quote Back to top
Ilinsekt
Post subject:   PostPosted: 06.05.2011, 19:04



Joined: 2010-10-29
Posts: 43

That's my understanding as well, but I _believe_ the point is: you have running X/KDM/whatever in version n, the d-u brings you version n+1. The package manager proceeds (at least in my experience, not with X, but minor upgrades of single packages). Now, regardless of wheter the new files are being written to the disk right now since X/KDM/whatever is completely in RAM or later when X/KDM/whatever quits, you now have other libraries in version n+1, which were compiled against X/KDM/whatever in version n+1. Now assume that these libraries are loaded dynamically at runtime (some plasmoids or kded services or systemsettings modules might be a good example). So now you have X/KDM/whatever version n loading a library version n+1, compiled against X/KDM/whatever in version n+1. Depending on the API and ABI changes between the versions, this can crash your system (just look at plasma-widget-networkmanagement with KDE 4.4 and 4.6. It's exactly the same version, but plasma-widget-networkmanagement compiled against KDE4.4 crashes plasma on 4.6) and interrupt the d-u, which puts dpkg in an inconsistent state, as has already been said.
 
 View user's profile Send private message  
Reply with quote Back to top
darioOffline
Post subject:   PostPosted: 06.05.2011, 19:04



Joined: 2010-11-27
Posts: 63

Status: Offline
If an application is running, it must be closed in order to uninstall it and replace it with another version, if i've understood your last question. If you close it, it stops working and if that application's job was to upgrade the system, this will be left in an inconsistent state, so you can't close it. The same thing could happen if the application crashes.
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT - 12 Hours
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by Zafenio