Increasing number of conflicts
in [Debian]
|
Prev: X Window System on Samsung n210 (Intel GMA 3150)
Next: PDF is blocked for printing, etc. OK for acroread (it behaves as expected), but KPDF allows me to print it, even if it is protected! Why?
From: B. Alexander on 20 Apr 2010 16:30 On Tue, Apr 20, 2010 at 10:57 AM, Monique Y. Mudama <spam(a)bounceswoosh.org>wrote: > On Tue, Apr 20 at 7:31, B. Alexander penned: > > > > In my case, it appears the root of the problems are caused by > > bitrot. I probably need to come up with some method of rebuilding > > my sid boxes every so often. Prior to this, my rebuilds were done > > in 2000 and 2007...Maybe if I am going to run sid, I need to plan > > for an annual rebuild of the system...At least the > > workstations... > > I've been running sid on a headless box since 2002 or thereabouts, > with config files copied from an even older RedHat box. No wipes / > rebuilds / etc. There may have been a few panicked moments along the > way, but I think almost all of them were hardware related. I may be > extraordinarily lucky, and I do think that the GUI packages add a lot > more complexity, or maybe simply a lot more packages and thus > opportunities for dependency problems. > Agreed. I have several servers that are running sid, and they don't have this type of problem. Most likely, because they are more static than a workstation. In addition, my servers don't have a GUI. > If by "bitrot" you mean that files are corrupted, I'd take a look at > my storage devices and filesystem settings. > No, no corruption. > If by "bitrot" you mean that config files and such are becoming > increasingly dated ... I do fight that all the time, or rather I keep > telling aptitude to keep my modified files, promise myself that I'll > eventually take a look at the differences, and almost never do. > It's more of a packaging issue. For instance, there have been several ABI changes, the most recent of which was the transition from kde3 to kde4. Packages getting left along the way. Another thing is packages whcih seem to have gotten confused by versions: luatex: Conflicts: texlive-base-bin (< 2008) but 2007.dfsg.2-8 is installed. python-kde4: Depends: python-sip4 (>= <none>) but 4.10.2-1 is to be installed. > I don't know if it matters that I almost always use the curses > interface to aptitude; I usually get the updates, then let them sit > for a few days to give the bug reports a chance to roll in. Anything > that shows up in apt-listbugs gets put on "hold", or when time allows, > investigated and permitted. Anything that seems like an unnecessary > removal or generally "smells wrong" gets put on "hold" as well. > Periodically I check out what's on "hold" to see if the dependencies > are fixed yet. > Generally, I use the command line version. I admit, I do upgrade immediately, but at the same time, I try to choose "non-critical" boxes to upgrade first. --b
From: Monique Y. Mudama on 20 Apr 2010 19:20 On Tue, Apr 20 at 16:19, B. Alexander penned: > It's more of a packaging issue. For instance, there have been > several ABI changes, the most recent of which was the transition > from kde3 to kde4. Packages getting left along the way. > > Another thing is packages whcih seem to have gotten confused by > versions: > > luatex: Conflicts: texlive-base-bin (< 2008) but 2007.dfsg.2-8 is > installed. > python-kde4: Depends: python-sip4 (>= <none>) but > 4.10.2-1 is to be installed. This might be a little painful for the KDE package, but I wonder what would happen if you uninstalled them and then reinstalled them. I'll admit, I've sometimes left packages on "hold" for months or even a year before trying to figure it out. Unless I specifically need a feature available in the latest version of a package, I just let things "work themselves out." This may not be an acceptable approach for everyone ... personally I find it better than the alternatives, which are 1) Run stable and have uniformly old packages (although I have a vague notion that stable versions are being released more often now than they used to be) 2) Run testing, which is really more an integration environment than a distribution - although I've just checked the rules, and again they seem to be much more friendly than I remember them. I remembered something like two weeks of clean living before a new version could make it to testing, but either I remember wrong or things have changed: http://www.debian.org/devel/testing Hrm. Thanks for starting this discussion. It seems that my understanding of the distributions is (not|no longer) valid, and I need to do some reading. -- monique -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100420231829.GI30298(a)mail.bounceswoosh.org
From: John Hasler on 20 Apr 2010 20:30 B. Alexander wrote: > I've got an issue with a sid box that I have been maintaining for a > while. This is my workstation, and I have noticed a growing number of > broken packages, unmet dependencies and conflicts. I have been using > safe-upgrade for months now, hoping that it would work itself out over > time. However, this hasn't happened. No, of course not. Sid is constantly undergoing the sort of changes that take place when you upgrade from one release to the next and which full-upgrade is designed to handle (and which safe-upgrade blocks): transitions, removal of obsolete packages, major version changes that require new library versions that may be incompatible with other packages, etc. Sid is often also in an inconsistent state when, for example, a package is uploaded in advance of its dependencies. By repeatedly running safe-upgrade you have forced these things to pile up. > So what can I do to fix the problems without losing functionality? "aptitude full-upgrade" and then patiently sort through the resulting mess. It might be simplest to write down all the proposed removals, let it do its thing, and then install the removed packages. > No problem. Most of my Debian installs at home run sid, with the rest > running testing...Except my firewall, which runs stable for the first > 6 months or so (until critical packages start getting long in the > tooth), then I upgrade it to testing and run until the next stable > release. I'm having trouble imagining what packages appropriate to a firewall could get long in the tooth. -- John Hasler -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/87hbn5d5xf.fsf(a)thumper.dhh.gt.org
From: Sjoerd Hardeman on 21 Apr 2010 05:00 B. Alexander schreef: > > > On Tue, Apr 20, 2010 at 8:07 PM, John Hasler <jhasler(a)debian.org > <mailto:jhasler(a)debian.org>> wrote: > > B. Alexander wrote: > > I've got an issue with a sid box that I have been maintaining for a > > while. This is my workstation, and I have noticed a growing number of > > broken packages, unmet dependencies and conflicts. I have been using > > safe-upgrade for months now, hoping that it would work itself out > over > > time. However, this hasn't happened. > > No, of course not. Sid is constantly undergoing the sort of changes > that take place when you upgrade from one release to the next and which > full-upgrade is designed to handle (and which safe-upgrade blocks): > transitions, removal of obsolete packages, major version changes that > require new library versions that may be incompatible with other > packages, etc. Sid is often also in an inconsistent state when, for > example, a package is uploaded in advance of its dependencies. By > repeatedly running safe-upgrade you have forced these things to pile > up. > > > So what can I do to fix the problems without losing functionality? > > "aptitude full-upgrade" and then patiently sort through the resulting > mess. It might be simplest to write down all the proposed removals, let > it do its thing, and then install the removed packages. > > > Yes. I need to block out some time and do just this. > > > > No problem. Most of my Debian installs at home run sid, with the rest > > running testing...Except my firewall, which runs stable for the first > > 6 months or so (until critical packages start getting long in the > > tooth), then I upgrade it to testing and run until the next stable > > release. > > I'm having trouble imagining what packages appropriate to a firewall > could get long in the tooth. > > > ssh, ssl, iptables, snort, etc. I don't have an extensively large > package list on my firewall, especially compared to a workstation, but > since it is on the sharp end of my network, I try to keep it as up to > date as is feasable. Then use stable, as security updates are often available earlier for stable than for testing. Up to date is something different than cutting-edge. Sjoerd PS. If you do need cutting-edge, use debian-backports!
From: Daniel Burrows on 30 Apr 2010 10:50
On Mon, Apr 19, 2010 at 02:54:20PM -0500, "Boyd Stephen Smith Jr." <bss(a)iguanasuicide.net> was heard to say: > On Monday 19 April 2010 08:16:02 B. Alexander wrote: > > I've got an issue with a sid box that I have been maintaining for a while. > > This is my workstation, and I have noticed a growing number of broken > > packages, unmet dependencies and conflicts. I have been using safe-upgrade > > for months now, hoping that it would work itself out over time. However, > > this hasn't happened. So what can I do to fix the problems without losing > > functionality? Below is the result of aptitude full-upgrade (forgive the > > cut-and-paste): > > I would use (aptitude full-upgrade), then when/if the first suggestion doesn't > meet with my approval, use the option to go into the ncurses interface at the > [Y/n] prompt. (Answer '?' to get the full list of valid responses.) > > (NB: The keystrokes below are from memory, they may be incorrect, but should > be in the aptitude documentation.) > > The ncurses interface will load and the current suggestion will be presented. > Use the arrow keys to highlight the most onerous part of the suggestion then > hit 'r' ([R]eject that action). Then, hit '.' to have aptitude comes up with > a different list of suggestions. You can do this from the command-line too. It used to be awkward to reject choices at the command-line, but in recent sid, the interface is a bit more stream-lined than it used to be: Remove the following packages: 1) ghc6-doc Leave the following dependencies unresolved: 2) libghc6-mtl-doc recommends ghc6-doc You can type "r 1" or "r 2" to reject option 1 or 2. Hit "?" at the prompt to get a list of the commands you can enter -- basically everything you could do at the interactive prompt. (you can also install or remove packages, but beware that this will restart your resolver session...hm, I really should add that warning to the online help) Daniel -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100430144346.GG22310(a)emurlahn.burrows.local |