Hi Boyd, Thanks for enthusiastic promotion of Debian unstable.
Please remember there are people behind packages and APT system only uses information provided by them. Overly confident on Debian system beyond its providers is not good for you. You know we run the stable system on most Debian servers. Have you thought about the reason behind why we have backports.org and we AS Debian use backports.org packages for partial upgrades of our stable servers? If things always work just using multiple archives with preferences and aptitude, .... we do not need backports.org packages for Debian servers. We can just have unstable. On Wed, Jan 27, 2010 at 08:45:13AM -0600, Boyd Stephen Smith Jr. wrote: > In <20100127131300.ge6...@osamu.debian.net>, Osamu Aoki wrote: > >> Do I need to create a preference file ?... > > > >These are tricks to fool APT. > > Not "fool". You are free to disagree. But we as Debian packagers assume users to use DEFAULT configuration and try to guarantee proper function under such condition. Debian provides you with lots of tools to override package maintainer judgement and expectation. This does not guarantee your action is the right one. > Apt, by default, treats all remote repositories in one of two > manners "get every package from there" (priority 500) or "get only the > packages I request from there" (priority 1 -- backports and experimental). So what? We know it and we do not expect people to play with preferences unless they know exactly the side effects of preferences > Using pinning, you can communicate to apt your actual preferences of > repositories. In my case, try to get all packages from > stable+security+volatile, but if you need them to satisfy dependencies or I > request a specific version you can pull from backports, > testing+volatile+security, unstable, and experimental in that order. But you as user are moving into situation where we as Debian developers do not guarantee package to function in the most robust way. To me, you are fooling APT system to make it do what DD might not have been anticipated. So please do not advocate such action without giving negative side. I know it works under some situation and I also know it does not work under other situation. I use it when I need it too. > >These do not solve the package version > >dependency issue. If it happen to be running, you are just lucky. > > Apt/aptitude will try as much as possible to make sure the various > dependencies of all installed packages are satisfied. If they fail, you > could > be in trouble. If they succeed but something still breaks, you are unlucky > (please file a bug). Pretty please, DO NOT DO THIS. We as DD do not appreciate this. Please run packages under pure unstable system if possible to report bugs. (If not, please make sure to analize situation carefully.) (Please do not feel bad. You are not alone making this misunderstanding. I made the same mistake and I was corrected by other DD. This is the reason behind the change of tone in "Debian Reference" http://www.debian.org/doc/user-manuals#quick-reference ) Please note that I install some unstable packages which I know they should work, like most bash programs, to my stable system. E.g. pbuilder. But I also know even some bash programs from unstable did not work in stable in previous releases. ( "-nt" was a new feature). That is why my Co-maintainer updated it to accommodate such usage. I know it by my first experience. > Preferences don't solve package dependency issues in isolation, but aptitude > can use the priorities when ranking it's solutions and deciding which > packages > to upgrade. Once you start pulling in packages from > testing/unstable/experimental, you will have to execute a full-upgrade more > often, and provide a bit a manual guidance to aptitude, but that's to be > expected. > > >If you can locally backport package, you should try it to be safe. > > I don't like doing this because I don't like having to provide my own > security > support. It is your prerogative to feel this way. > >If not, it is best not to do this kind of mixed system to avoid > >problem. > > Having run a mixed desktop and 2 mixed servers since before Lenny was > released, I disagree with this statement. It allows the packages whose > development I'm not currently following is remain dependable (pulled from > stable or at least testing) while letting me pull packages with new, shiny > features that I must try from unstable or experimental. Lucky you. This is just your case. > I really do find it to be a best-of-both-worlds situation. My configuration > is documented at http://iguanasuicide.net/node/4. Recently, many packages are built with strict version dependencies. So there may be fewer problematic cases arising with such set up since they tends to pull in required version packages. But giving blanket guarantee without fair warning is irresponsible. Osamu -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org