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

Re: Sources.list to track stable and allow install from testing



On Wed, Aug 07, 2002 at 00:57:21 -0700, David De Graff wrote:
> If I want to be able to install some packages from testing (sarge?) while
> tracking mainly stable (woody?), I gather that I need to add lines to
> sources.list that identify a testing distribution.

Yes.

> My best guess at the sources.list for this reads as follows:
> -----------------------
[...]
> deb http://non-us.debian.org/debian-non-US stable/non-US main contrib
> non-free
> deb-src http://non-us.debian.org/debian-non-US stable/non-US main contrib
> non-free
[...]
> deb http://non-us.debian.org/debian-non-US stable/non-US main contrib
> non-free
> deb-src http://non-us.debian.org/debian-non-US stable/non-US main contrib
> non-free
> 
> deb http://security.debian.org/ stable/updates main contrib non-free
> -----------------------

[...]
> - Why would 'apt-get update' complain about duplicates with the sources.list
> above?

Because there are duplicated lines. See above.

> - What's the correct sources.list layout to enable tracking stable while
> grabbing some packages from testing once in a while?

It's OK, except for the duplicated lines.

> - Should deb-src be included as well as deb for the testing distribution
> list(s)?

I think that this depends on if you want the sources or not.

> BTW, if I have testing in the list, should security stay there too?

Yes, it's for security updates.

> I've read in some of the docs that security should be used only for
> stable since testing changes often. But then I want to track stable,
> so I would expect that security should remain in the list.

Well, security updates are also useful when using the testing
distribution, as testing doesn't change so often. Security updates
sometimes (often?) appear before the update of the testing version.
Thus, you may want to apply security updates even if you have the
testing version, in particular when the testing version and the
stable version of the package are the same one (as woody has just
appeared, this is often the case for the moment). To get that,
I needed to clear the file /etc/apt/apt.conf and to create the
file /etc/apt/preferences (after some discussions in the French
Debian mailing-list):

Package: *
Pin: release a=stable
Pin-Priority: 900

Package: *
Pin: release a=testing
Pin-Priority: 900

Package: *
Pin: release a=unstable
Pin-Priority: 200

because due to security updates, stable versions may be higher than
testing versions. With these priorities, between the testing version
and the stable version of a package, I always have the higher one.

But since you preferably want the stable version, you do not need
such trick.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA



Reply to: