Andrei POPESCU wrote: > Bob Proulx wrote: > > > What would happen if I would commented wheezy lines by using a # and > > > after that I run 'aptitude update' and 'aptitude safe-upgrade'? > > > > Nothing different would happen from what you have today. You already > > have Sid listed in your sources.list system. If you have upgraded to > > Sid packages then you already have a Sid system. Removing the Wheezy > > lines will do nothing different than you have today. Or leaving them > > in. Other than taking up more memory and running slower because of > > the need to process so much more data, leaving those Wheezy lines in > > won't matter either. I would take them out just to simplify things. > > I wouldn't :D
And you post a very interesting counter-point. > > Right about now there are ten people jumping at the chance to correct > > me and say, no, that isn't true, Squeeze has package XYZ that was > > removed from Sid and Wheezy, and Wheezy has the pre-transition version > > of package ABC that was removed from Sid. They will say that they are > > really different. Yes, yes, yes to all. They are different release > > tracks, have their own repositories. Some individual packages or > > transitions of packages will have been added and removed between the > > different repositories. Each and every one of those are special cases > > that would need to be discussed separately. Which is too much to talk > > about in a quick answer so I am going to ignore this for now. > > Unless I'm misreading your paragraph above you are not mentioning the > case where packages are being removed from unstable temporarily, to ease > a (very) complicated transition. I would say that case was covered under the very large door I opened mentioning transitions of packages which will have been added or removed between the different repositories. I really didn't want to write a reference for all possible cases. And for example you mentioned pinning and I left that out entirely. > Something like "unstable users should have testing in their > sources.list, period." has been posted a few years ago by a member of > the Release Team (Adeodato Simò, if memory serves me) and my reading of > -devel and -devel-announce didn't suggest any (major) change in this > recommendation. That is a very interesting point. I had not encountered that strategy before. Hmm... Would keeping Testing in the list along with Sid make for a system where things are generally more installable? It probably would! I will need to consider this longer but I think you have raised a very good point and have convinced me that Testing+Unstable is a valid and useful combination that exists between them. For me on Sid systems I already have installed everything that I want to install. So temporary transitions where packages have been removed only very rarely affect me. But I am concerned about upgrades. I usually upgrade daily in order to be able to catch problems and file bugs as soon to the problematic upload as possible. And I am concerned about upgrades from Stable so that the next release is in good shape for things I care about. But I haven't been focusing on whether something I care about is installable or not in Unstable. I am confident that won't slip into a release. If I run into a problem with an uninstallable package in Unstable I simply deal with it at the time that it happens. It isn't unusual to have a package that is uninstallable in Sid due to broken dependencies. But when I hit those problems I usually use the archive.debian.net repository and manually select a contour version of packages. For many people being able to select versions from Testing seems easy and reasonable. > Hmm, maybe I should try to get the Release Team's current opinion on > this and suggest a patch for the Debian Reference... If you do then I would be very interesting to know the result. Thanks! Bob
signature.asc
Description: Digital signature
