Camaleón <noela...@gmail.com> writes: > On Sun, 02 Sep 2012 19:31:02 +0200, lee wrote: > >> Camaleón <noela...@gmail.com> writes: >> >>>> Some packages currently installed may be from unstable or experimental >>>> because I needed more recent versions of them --- IIRC, the mumble >>>> ones are. I would want to keep those until testing catches up. >>> >>> Then this can be the culprit for all your mess unless you had configure >>> apt repositories priorities properly. >> >> What's wrong with it? Aptitude installs packages from testing by default >> and installs packages from unstable or experimental when I tell it to, >> which is what I want. > > Nothing wrong "per se" but when using such mixed repositories you have to > carefully watch for what gets installed/updated, from where it comes and > if the update routine is finally doing what you wanted to do. In brief, > you have to be very cautious or your system can badly break.
I'm paying attention to that in any case. It's pretty easy, I just look at what aptitude would do, and if I don't like it, I don't let it do what it wants. I don't override dependencies and only install software that isn't in either Debian or Debian-multimedia when it really cannot be avoided. If package maintainers set up dependencies in such a way that stuff installs flawlessly and then something breaks, I'll have a problem. There probably isn't any good way to prevent that, other than building everything from scratch, which would involve to take care of all dependencies myself. That would probably be worse. And what is worse? Having to wait until a bugfix finally makes it into a Debian package that is in stable (or testing) or use a Debian package from unstable or, if that cannot be avoided, from experimental --- or ignore the package management and get the source and compile and install yourself whatever you need? >>>> ,---- >>>> | lee@yun:~$ LANG=C apt-cache policy >>> >>> (...) >>> >>> What the hell is all that bunch of repositories? :-O >>> >>> You need an urgent reorganization for your repos and also reducing the >>> number of them as you have too many defined. >> >> Why? > > To avoid your system from trying to downgrade a bunch of core > packages? ;-) Aptitude doesn't try that. If I removed unstable and experimental, what other choice would there be but to downgrade packages, leaving me with some stuff not working since packages from unstable are installed *because* there have been bugfixes? Maybe I don't understand the problem, so let's take the mumble server for an example: There was a regular update to it in testing, and that version didn't work at all. There was a bug report about it and the bug was fixed in the next version, and that version was available in unstable, so I installed the version from unstable and it works fine. What's the problem, and what's a better alternative? >> If I was to remove unstable and experimental, how would I install >> packages from these when needed? > > You can't but then you have to know how proceed under this scenario. I > mean, having a complete mix of stable/testing/unstable/experimental and > external repositories is not for beginners: you have to understand in > deep how this works. Well, I haven't installed packages from stable. I have installed mumble-server from unstable, and I tried NVIDIA drivers from unstable and experimental and went back to the ones in testing. That's all I did, besides having a current git version of emacs24 (because there have been fixes to gnus which aren't available in Debian yet) in /usr/local and a couple libraries (which are needed by some software I'm using), all of which the package management doesn't know about at all. So when the package management figures that it needs to install package X, Y and K when I install package Z from unstable (because I need the more recent version of Z) and I let it do that, is there something wrong with that? Of course, any of the packages X, Y, K and Z from unstable could be worse than the same packages in testing. There isn't anything I could do about that, though. The alternative is getting the upstream sources of what's in package Z and make my own version, completely ignoring any dependencies which might be important. Is that the better choice? And if it is and when I do that, I need to somehow keep track of such software and either have to revert to the Debian versions of the software once a more recent version is available or update from upstream or just leave it until it quits working for some reason. That doesn't seem to be a good choice to me. Having some packages from unstable installed along with the ones from testing is a situation that will "fix" itself over time when more recent versions of these packages make it into testing, replacing the ones from unstable. In the meantime, I have a working system without having to worry about keeping track of self-installed software and dependency problems that might arise from it. Just don't circumvent the package management --- I tried that many years ago and found out it's a very bad idea, so I don't do that. >> And if I removed Debian multimedia, I would miss a lot of packages. > > Sure, such is life :-) > > Or you can also "cherry pick" some packages from d-m and then turn off > this repository from your sources.list. And turn it back on every time I check for updates? Or skip the updates and only turn it back on when dependency problems come up because the cherry-picked packages have become too old? >> Perhaps I don't need the security updates because there aren't any for >> testing, but they don't seem to hurt anything. > > Security updates is one of the repos I would leave. But I'm afraid I have > a completely point of view than yours about how to use a system, I mean, > I prefer stability over new features and you seem to look for the > opposite. Anyway, if that's your case, I would simply install "sid" and > problem solved :-) Nope, reliability is much more important to me than new features. It's not about new features, it's about having what you need. If I was running stable, I won't install exim4 from testing or unstable because it has five or ten new features I don't need or a fix for two bugs that never occur in my application. When I need the features, I start thinking about it. When the bugs occur in my application and I need the fix, I'm likely to install the version from testing/unstable to get things working. When my X-session randomly freezes and I suspect it's due to NVIDIA drivers, I'm looking for more recent ones and try them because the problem might be fixed already. Besides, look at the NVIDIA drivers in stable: They are ancient. There have been significant improvements, and I'm lucky that I'm running testing which has these improved drivers because it matters to me. For a server, it won't matter and I'd just stay with the nouveau drivers if they work fine for that. Reliability is actually the reason why I'm running testing instead of stable: When you run stable, you have to make relatively big leaps when you upgrade from one stable release to the next. You don't need that with testing as the leaps are relatively small and don't happen all at once and thus are much easier to handle. It's trading one risk for another. >>>> While (unsuccessfully) trying to use more recent NVIDIA drivers >>>> because with the ones from testing the X-session randomly froze, I >>>> added the i386 architecture because that was recommended. I'm not so >>>> sure if that was a good idea ... Fortunately, the freezing problem >>>> seems to have been fixed :) >>> >>> At a high cost, I'd say... >> >> Well, what do you do when your X-session randomly freezes? > > Report it? What is for sure is that I'm not going to sacrifice my whole > system stability for a VGA problem. There wasn't anything useful to report because the only thing I could do was pressing the reset button. The freeze might not occur for two days and might occur twice within an hour or only once a day. It wasn't reproducible, and since I had to press reset, there wasn't any information I could have provided. I have no way of telling what caused the problem, it might have been something else than the NVIDIA drivers. I haven't sacrificed the stability of the whole system by trying out more recent NVIDIA drivers. With the random freezes, the stability was gone already. The package management makes sure you have the needed packages in the needed versions installed when you do that --- if it doesn't, it needs to be fixed. The only problem is downgrading from the more recent drivers since the package management didn't handle that well, which is something to improve upon. >> You have two choices: > > (...) > > Or maybe more, but this thread is not about this. I would suggest that > you open a new one if you want to explain these problems in detail or if > you're still concerned about your available options. > >> When using the packet management means high cost, what else do you >> suggest to use? > > Using the package manager is not the problem here. The problem is mixing > "all" Debian flavours and think this is going to magically work with no > additional tweaks ;-) It's working fine, so I'm not worrying about it. If there are packages in testing that don't work together with packages from unstable, I expect the packet management to tell me this, and so far it does so nicely. Do you have an example for a tweak that would be required to make? -- Debian testing amd64 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcfvnkmk....@yun.yagibdah.de
