[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian SID or Wheezy/SID?

On Sun, Feb 19, 2012 at 1:35 PM, Bob Proulx <bob@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:
but it'd be good to have an update to Debian Reference clarifying the
official policy - if there is one (!).

Reply to: