On Sun, Feb 19, 2012 at 1:35 PM, Bob Proulx <b...@proulx.com> wrote: > 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.
This is the 2009 link that Andrei posted almost exactly a year ago: http://lists.debian.org/debian-devel/2009/03/msg00582.html but it'd be good to have an update to Debian Reference clarifying the official policy - if there is one (!). -- 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/CAOdo=SxjA+2B+9vrPKxHdb=4ttbh8wpzvtq6dr3di69adm9...@mail.gmail.com
