Bug#165365: marked as done (apt: APT::Default-Release should accept release codenames)
Your message dated Tue, 22 Oct 2002 10:26:52 +0200
with message-id <[🔎] 20021022082652.GE23321@vitel.alcove-fr>
and subject line Bug#165365: reopen
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 18 Oct 2002 14:55:34 +0000
>From ydirson@fr.alcove.com Fri Oct 18 09:55:34 2002
Return-path: <ydirson@fr.alcove.com>
Received: from ns1.alcove-solutions.com (smtp-out.fr.alcove.com) [212.155.209.139]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 182YXF-000052-00; Fri, 18 Oct 2002 09:55:34 -0500
Received: from vitel.alcove-fr ([10.16.10.8])
by smtp-out.fr.alcove.com with esmtp (Exim 3.12 #1 (Debian))
id 182YVs-0006r0-00; Fri, 18 Oct 2002 16:54:08 +0200
Received: from ydirson by vitel.alcove-fr with local (Exim 3.35 #1 (Debian))
id 182YX2-0007IR-00; Fri, 18 Oct 2002 16:55:20 +0200
Date: Fri, 18 Oct 2002 16:55:20 +0200
From: Yann Dirson <dirson@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: apt: APT::Default-Release should accept release codenames
Message-ID: <[🔎] 20021018145519.GA27938@vitel.alcove-fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.25i
X-Reportbug-Version: 1.50
Sender: Yann Dirson <ydirson@fr.alcove.com>
Delivered-To: submit@bugs.debian.org
X-Spam-Status: No, hits=-7.2 required=5.0
tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT,
USER_AGENT_MUTT
version=2.41
X-Spam-Level:
Package: apt
Version: 0.5.4
Severity: normal
There are currently a number of features in testing that justify
having a production server point both to woody as stable, and to
testing. In this case, the APT::Default-Release setting should be
"woody". I don't want to ever see "stable" here, as I want to control
when transitionning from woody to sarge, and already saw customers
with _broken_ machines halfway between potato and woody, just because
their sources.list blithely pointed to "stable".
However, I can't just use codenames - even with "install
package/release", although I thought this one had worked in the past.
It looks like the codename should be added to Release files for the
necessary information to be available ?
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux vitel 2.4.19-station #1 Tue Aug 6 11:36:58 CEST 2002 i686
Locale: LANG=french, LC_CTYPE=french
Versions of packages apt depends on:
ii libc6 2.2.5-6 GNU C Library: Shared libraries an
ii libstdc++2.10-glibc2.2 1:2.95.4-7 The GNU stdc++ library
--
Yann Dirson <Yann.Dirson@fr.alcove.com> http://www.alcove.com/
Technical support manager Responsable de l'assistance technique
Senior Free-Software Consultant Consultant senior en Logiciels Libres
Debian developer (dirson@debian.org) Développeur Debian
---------------------------------------
Received: (at 165365-close) by bugs.debian.org; 22 Oct 2002 08:26:55 +0000
>From ydirson@fr.alcove.com Tue Oct 22 03:26:54 2002
Return-path: <ydirson@fr.alcove.com>
Received: from ns1.alcove-solutions.com (smtp-out.fr.alcove.com) [212.155.209.139]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 183uNK-0006iz-00; Tue, 22 Oct 2002 03:26:54 -0500
Received: from vitel.alcove-fr ([10.16.10.8])
by smtp-out.fr.alcove.com with esmtp (Exim 3.12 #1 (Debian))
id 183uM8-0005kB-00; Tue, 22 Oct 2002 10:25:40 +0200
Received: from ydirson by vitel.alcove-fr with local (Exim 3.35 #1 (Debian))
id 183uNJ-000131-00; Tue, 22 Oct 2002 10:26:53 +0200
Date: Tue, 22 Oct 2002 10:26:52 +0200
From: Yann Dirson <ydirson@fr.alcove.com>
To: Jason Gunthorpe <jgg@debian.org>
Cc: Yann Dirson <ydirson@fr.alcove.com>, 165365-close@bugs.debian.org,
APT Development Team <deity@lists.debian.org>, ftpmaster@debian.org
Subject: Re: Bug#165365: reopen
Message-ID: <[🔎] 20021022082652.GE23321@vitel.alcove-fr>
References: <[🔎] 20021021155226.GV23321@vitel.alcove-fr> <[🔎] Pine.LNX.3.96.1021021181320.19197B-100000@wakko.debian.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[🔎] Pine.LNX.3.96.1021021181320.19197B-100000@wakko.debian.net>
User-Agent: Mutt/1.3.25i
Sender: Yann Dirson <ydirson@fr.alcove.com>
Delivered-To: 165365-close@bugs.debian.org
X-Spam-Status: No, hits=-16.0 required=5.0
tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT,
USER_AGENT_MUTT
version=2.41
X-Spam-Level:
On Mon, Oct 21, 2002 at 06:22:21PM -0600, Jason Gunthorpe wrote:
> You can write in a version number too, though the format is not so nice..
> Perhaps you should ask ftpmaster to include version symlinks that don't
> include the release sub version. I think that's a good idea and then
> you can encourage people to use '3.0' in their S.L and '3.0' as their
> pinning specs.
Will try to think of it :)
> Personally I think the last release is going to be the last one that uses
> codenames at all. They only existed to make FTP maintinance easier and the
> pool scheme is a much better approach.
Well, maybe. However, codenames
1/ have an affective aspect that numeric versions don't have
2/ provide a means of talking about a release before it gets a numeric
version assigned
Thus I'm not sure they will disappear at all. I also note that at
least RH and MDK also codename their releases. In another world
ChorusOS also does - and I don't remember that this as as much of a
technical meaning than what we had ourselves :)
> It doesn't work that way anymore. unstable is called unstable,
> it has no code name and no version number.
Sure.
> Testing is the closest thing to what unstable used to be, but the way it
> is used today you either follow testing or you don't. It's pointless to
> only track testing until a release happens then fall back to stable -
> unless we are nearing a release, in which case testing will have a release
> version number, and you can pin to it.
Yes, that was my primary concern. It may be reasonable enough for me :)
Thanks,
--
Yann Dirson <Yann.Dirson@fr.alcove.com> http://www.alcove.com/
Technical support manager Responsable de l'assistance technique
Senior Free-Software Consultant Consultant senior en Logiciels Libres
Debian developer (dirson@debian.org) Développeur Debian
Reply to: