On Friday 29 January 2010 08:11:06 Osamu Aoki wrote: > Thanks for enthusiastic promotion of Debian unstable. What? No. I don't run unstable. I run stable on my servers (this can be verified by checking /etc/debian-release or the version number of a random sampling of packages) and testing on my desktop (I had to have KDE 4; same verification process). The output of aptitude in the middle of a library transition in unstable kinda freaks me out. Also, mixed systems like mine are very sensitive the ABI compatibility guaranteed by Debian policy, and unstable breaks ABI far more often than testing. > 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. I also know that many eyes watch Debian packages, and that Debian provides a lot of tools to verify packages match policy. Yes, there are going to be mistakes, but when Debian policy is followed, running a mixed system is not a problem. > You know we run the stable system on most Debian servers. I run stable on my servers as well. > 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? They provide newer upstream versions (which may include new features, or fix issues that are not generally release-critical but may be important to this server) without requiring a library transition. Depending on how long it has been since stable has been released, some libraries could have made an ABI transition. When that happens, pulling a package from testing may require unwanted upgrades (both of libraries and even unrelated applications) in order to satisfy all dependencies. Backports policy for package is different than testing, so this is not an issue with backports. > 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. That's not true at all. Backports serves a very important role, which is why I have my apt preferences set to use backports for things before using testing/unstable/experimental. Backports isn't just another testing with a longer bug delay or where lower priority bugs prevent automatic package transition, it has a different policy on how different it can be from stable, and I applaud the goals of making backports (and volatile) part of the official mirror system. > On Wed, Jan 27, 2010 at 08:45:13AM -0600, Boyd Stephen Smith Jr. wrote: > > In <[🔎] 20100127131300.GE6468@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. "fooling" APT would be communicating information to APT that was either incorrect or more simplistic that what APT would normally use. I am using my apt preferences file to provide APT with accurate additional information that it did not have before, hardly "fooling" it. > But we as Debian packagers assume users to > use DEFAULT configuration and try to guarantee proper function under such > condition. Right, (I hope) no one expects the package maintainers to test every possible combination. > Debian provides you with lots of tools to override package > maintainer judgement and expectation. This doesn't override maintainer judgement. It doesn't say "assume package X is installed"; it doesn't say "satisfy dependencies for package X with package Y". It may not be their expectation, but every system is mixed in the middle of an upgrade, so some part of their expectation covers a mixed system. It does increase the pool of packages available, but it doesn't go outside the official and semi-official repositories -- where Debian policy guarantees upgrades from a stable package to a backports package to a testing package to a unstable package with work. > This does not guarantee your > action is the right one. Oh, I agree. A stable system is fully "supported" while mixed systems are not "supported". Of course, since backports is not an official repository it is also not "supported". At least, that's policy. Truth is, a pure stable system is something few users are ultimately happy with as a desktop. Adding backports might get you the package you were hoping for. Adding debian-multimedia can make things a lot easier as far as dealing with the randomness of file formats available on the Internet. At some point the may, like myself, start backporting packages themselves for private use using a stable pbuilder set-up, with lintian and piuparts. At all these points, you can basically get the same level of support for you system. The forums and mailing lists are still open to all and few will refuse to advise you because you've got a non-stable system. Even bugs.d.o remains a resource, at least until your problem touches on a specific package that some maintainer doesn't trust. Eventually though, they may find that the package version they want, whether it fixes a pet bug or it is just some "new hotness", is not in their favorite, mostly compatible repositories. It doesn't appear to be backportable as it clearly uses API that's not in the stable library headers. They could upgrade wholesale to testing or unstable, but that can lead to far more instability (not crashing, just frequent [and sometimes troublesome] upgrades) than they are ready for. A mixed system is great in this case. > Please > run packages under pure unstable system if possible to report bugs. That's *NOT* Debian policy. DDs are responsible for *all* their official package versions, not just unstable. > (Please do not feel bad. You are not alone making this > misunderstanding.) Please provide a Debian policy document reference that says DDs get to ignore testing and stable. > Please note that I install some unstable packages which I know they > should work, like most bash programs, to my stable system. I avoid unstable for the most part. I would much rather pull a package from backports or testing than unstable. > > >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. The main avenue for support for mixed systems is just as reliable as the main avenue for support for pure-stable or pure-unstable systems: the mailing lists and forums. Things are *less likely* to break in a mixed stable/backports/testing/unstable environment than in the purely unstable environment. The list archives bears that fact out. > > 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. Fair Warning: Mixed systems are "unsupported". In theory, this means that you won't be able to use the Debian support infrastructure to deal with issues that may arise during your use of a mixed system. In practice, you have the same resources available as everyone else running Debian: a bunsh of volunteers. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.