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:
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 (!).
Reply to: