------------------------------------------------------------------------
Content-Type:
text/plain
debian-devel-digest Digest Volume 2003 : Issue 1722
Today's Topics:
Re: apt 0.6 in experimental [ Matt Zimmerman <mdz@debian.org> ]
Re: Bug#224742 acknowledged by devel [ Henning Makholm <henning@makholm.ne ]
Re: apt 0.6 in experimental [ Florian Weimer <fw@deneb.enyo.de> ]
Re: Bug#224742: Related to this issu [ Henning Makholm <henning@makholm.ne ]
Re: Bug#224742: Related to this issu [ Henning Makholm <henning@makholm.ne ]
Re: apt 0.6 in experimental [ George Danchev <danchev@spnet.net> ]
Re: apt 0.6 in experimental [ Matt Zimmerman <mdz@debian.org> ]
Re: Bug#224742 acknowledged by devel [ Martin Loschwitz <madkiss@debian.or ]
Re: So many packages. So few that I [ Sean 'Shaleh' Perry <shaleh@speakea ]
Re: Bug#224742: Related to this issu [ Steve Langasek <vorlon@netexpress.n ]
Re: Linux 2.6.0 [ Andres Salomon <dilinger@voxel.net> ]
bug #151273: linneighborhood: packag [ Will Lowe <harpo@thebackrow.net> ]
Re: Bug#224742 acknowledged by devel [ Henning Makholm <henning@makholm.ne ]
Re: Bug#224742: Related to this issu [ Henning Makholm <henning@makholm.ne ]
Re: Bug#224742: Related to this issu [ Henning Makholm <henning@makholm.ne ]
Re: apt 0.6 in experimental [ "Nathaniel W. Turner" <nate@houseof ]
Re: apt 0.6 in experimental [ Joey Hess <joey@kitenet.net> ]
Re: Bug#224742: Related to this issu [ Steve Langasek <vorlon@netexpress.n ]
------------------------------------------------------------------------
Subject:
Re: apt 0.6 in experimental
From:
Matt Zimmerman <mdz@debian.org>
Date:
Sun, 28 Dec 2003 16:11:33 -0800
To:
debian-devel@lists.debian.org, 203741@bugs.debian.org
To:
debian-devel@lists.debian.org, 203741@bugs.debian.org
Message-ID:
<[🔎] 20031229001133.GF17472@alcor.net>
Content-Type:
text/plain; charset=us-ascii
Content-Disposition:
inline
On Sun, Dec 28, 2003 at 02:28:18PM -0800, Matt Zimmerman wrote:
apt 0.5 downloads dists/<dist>/<section>/<binary,source>/Release for use in
policy calculations. apt 0.6 does not download that file at all, and
downloads dists/<dist>/Release for use in authentication. However, 0.6
still tries to read dists/<dist>/<section>/<binary,source>/Release, which
has not been downloaded.
This could be fixed one of two ways:
1. Use dists/<dist>/Release for both purposes (authentication and pinning).
This is trivial, and works fine for the Debian archive (dists/<dist>/Release
is more or less a superset of
dists/<dist>/<section>/<binary,source>/Release), but could have unknown
effects for third-party repositories which provide per-section Release
files.
2. Continue to download them all. This requires some further changes to the
apt-secure code.
Personally, I find the distinction between these two types of Release files
to be confusing, and would prefer (1) as it is much simpler. However, I
don't know whether there is a rationale for why things were done as they
were for apt-secure, and whether the top-level Release file is intended to
replace the others.
After discussing this with Colin Walters, I've implemented (1.) in apt
0.6.4, which has been uploaded to experimental.
------------------------------------------------------------------------
Subject:
Re: Bug#224742 acknowledged by developer (Re: Bug#224742: Related to
this issue...)
From:
Henning Makholm <henning@makholm.net>
Date:
28 Dec 2003 23:23:06 +0000
To:
John Lines <john@paladin.demon.co.uk>
To:
John Lines <john@paladin.demon.co.uk>
CC:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 873cb4edd1.fsf@kreon.lan.henning.makholm.net>
Content-Type:
text/plain; charset=ISO-8859-1
Content-Transfer-Encoding:
8bit
Scripsit John Lines <john@paladin.demon.co.uk>
except that ifupdown will complain if it happens to be the
empty string.
If it did accept an empty string, and treat it as meaning false,
like perl (for example) then I suspect this would lead to more
confusion and bug reports.
Why should the empty string for a dummy parameter have any special
significanse?
------------------------------------------------------------------------
Subject:
Re: apt 0.6 in experimental
From:
Florian Weimer <fw@deneb.enyo.de>
Date:
Mon, 29 Dec 2003 01:19:50 +0100
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 20031229001950.GA18566@deneb.enyo.de>
Content-Type:
text/plain; charset=us-ascii
Content-Disposition:
inline
Matt Zimmerman wrote:
Signatures are verified only during "apt-get update", right?
It rather see a warning during install/upgrade/source, too, if the
signature does not match or the key has expired.
The way it works is that signatures are verified during apt-get update, and
a warning is displayed during install/upgrade *only* if packages are being
installed from a source which was not authenticated.
My interpretation of the test results didn't take into account the
unstable/experimental interaction mentioned in another part of this
thread.
Once that has been sorted out, I'll retest.
------------------------------------------------------------------------
Subject:
Re: Bug#224742: Related to this issue...
From:
Henning Makholm <henning@makholm.net>
Date:
28 Dec 2003 23:34:37 +0000
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 87y8swcy9e.fsf@kreon.lan.henning.makholm.net>
Content-Type:
text/plain; charset=iso-8859-1
Content-Transfer-Encoding:
8bit
Scripsit Steve Greenland <steveg@moregruel.net>
On 27-Dec-03, 17:28 (CST), Henning Makholm <henning@makholm.net> wrote:
The non-tecnical issue - namely his attempts to threaten Enrico into
submission by abusing his BTS power rather than explaining why he
thinks as he does *is* in my book completely unreasonable.
Why is that a problem, yet Enrico's attempt to bludgeon AJ into
submission by repeatedly re-opening a wish-list item
How can a wishlist item be used to "bludgeon" in any way?
I have asked this repeatedly and not yet gotten any answer.
But that's basically what the constitution says: the maintainer of a
package has the biggest gun with regard to that package.
Noone has ever contested that.
The point of the thead is that the maintainer is *also* trying to have
the biggest gun with respect to what others *think* about the package.
That is fundamentally wrong.
Since Enrico's suggestion is purely aesthetic, it's perfectly within
the maintainer's purview to reject it.
Noone has ever contested that.
Closing the "bug" is one acceptable way to do so.
There is a "wontfix" tag for that. Rather, closing the wishlis itemt
is a way of asking the submitter to acknowlege that his request was
silly in the first place. Refusing to let the submitter *not*
acknowledge this, under threat of BTS exclusion, is repression of the
submitter's right to have his own thoughts about the issue.
Repeatedly re-opening a bug because one disagrees with the response is
pretty much unacceptable,
*Not* reopening would be an admission of having been wrong in filing
the original request.
and does constitute abuse of the BTS.
No·
There are superior ways to appeal a maintainer decision.
The submitter did not wish to appeal - just to go on record as
disagreeing.
------------------------------------------------------------------------
Subject:
Re: Bug#224742: Related to this issue...
From:
Henning Makholm <henning@makholm.net>
Date:
28 Dec 2003 23:35:33 +0000
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 87u13kcy7u.fsf@kreon.lan.henning.makholm.net>
Content-Type:
text/plain; charset=ISO-8859-1
Content-Transfer-Encoding:
8bit
Scripsit Kalle Kivimaa <killer@debian.org>
Henning Makholm <henning@makholm.net> writes:
A prerequisite for this is that discussion of the decisions is not
summarily rejected with reference to the constitution.
Umm, nobody except the listmasters can reject discussions on
debian-devel :)
You implied that it was inappropriate to discuss the BTS owner's
actions, because the constitution give them first say in what happens.
------------------------------------------------------------------------
Subject:
Re: apt 0.6 in experimental
From:
George Danchev <danchev@spnet.net>
Date:
Mon, 29 Dec 2003 02:30:04 +0200
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 200312290230.04731.danchev@spnet.net>
Content-Type:
text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:
7bit
Content-Disposition:
inline
On Monday 29 December 2003 00:52, Matt Zimmerman wrote:
On Mon, Dec 29, 2003 at 12:11:32AM +0200, George Danchev wrote:
Ok, one more thing. It would be nice if by downloading with apt-get
source, dpkg-source (or apt-get itself) processes the *.dsc file and
checks if the signature is good ad if so if the sums match. Also in sace
of mismatch apt-key to suggest upgrade or rsync debian-keyring.
apt 0.6 will provide similar prompting for "apt-get source" as "apt-get
install". apt will not attempt to interpret the .dsc file; that is
dpkg-source's job. dpkg-source already verifies the checksums, and
dscverify is available to check the signature.
Thanks for the clarification. I hope Javier won't miss this and will add it to
the 'securing-debian-howto' about how to verify debian's source packages.
My suggestion and personal point of view is that dscverify utility must be
included in dpkg src tree (and not in devscripts's one) ... also there should
be an option srcsigs/no-srcsigs for /etc/dpkg/dpkg.cfg to control weather
dpkg-source to call dscverify or not ... similar to no-debsigs option for
debs.
One could really lost himself within the cosmopolitic world of debian.
------------------------------------------------------------------------
Subject:
Re: apt 0.6 in experimental
From:
Matt Zimmerman <mdz@debian.org>
Date:
Sun, 28 Dec 2003 16:31:19 -0800
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 20031229003119.GG17472@alcor.net>
Content-Type:
text/plain; charset=us-ascii
Content-Disposition:
inline
On Mon, Dec 29, 2003 at 01:19:50AM +0100, Florian Weimer wrote:
Matt Zimmerman wrote:
Signatures are verified only during "apt-get update", right?
It rather see a warning during install/upgrade/source, too, if the
signature does not match or the key has expired.
The way it works is that signatures are verified during apt-get update, and
a warning is displayed during install/upgrade *only* if packages are being
installed from a source which was not authenticated.
My interpretation of the test results didn't take into account the
unstable/experimental interaction mentioned in another part of this
thread.
Once that has been sorted out, I'll retest.
Grab 0.6.4 from incoming.
------------------------------------------------------------------------
Subject:
Re: Bug#224742 acknowledged by developer (Re: Bug#224742: Related to
this issue...)
From:
Martin Loschwitz <madkiss@debian.org>
Date:
Mon, 29 Dec 2003 01:02:18 +0100
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 20031229000218.GA7314@minerva.local.lan>
Content-Type:
multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP"
Content-Disposition:
inline
On Sun, Dec 28, 2003 at 03:59:35PM +0100, Marc Haber wrote:
You're stopping Enrico from voicing deviant thoughts then you threaten
to cut him off from the BTS unless he starts pretending not to think
them.
The threat has become reality. I find this very disturbing, and one
more piece of evidence that the project is in reality run by a cabal.
I really don't get why you want to blame aj. In my opinion, he perfectly
fulfills his jobs as release manager: Avoid news bug reports means making
a release possible sooner. Yay for aj!
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
------------------------------------------------------------------------
Subject:
Re: So many packages. So few that I need started at every boot.
From:
Sean 'Shaleh' Perry <shaleh@speakeasy.net>
Date:
Sun, 28 Dec 2003 16:23:43 -0800
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 200312281623.43211.shaleh@speakeasy.net>
Content-Type:
text/plain; charset="utf-8"
Content-Transfer-Encoding:
7bit
Content-Disposition:
inline
On Saturday 27 December 2003 17:19, Matthew A. Nicholson wrote:
Couldn't you use different runlevels to achieve this?
Runlevels are not always the best choice. Switching runlevels means stopping
and starting other services. On a desktop this is probably ok -- on a server
it probably isn't.
------------------------------------------------------------------------
Subject:
Re: Bug#224742: Related to this issue...
From:
Steve Langasek <vorlon@netexpress.net>
Date:
Sun, 28 Dec 2003 19:27:51 -0600
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 20031229012751.GA14732@quetzlcoatl.dodds.net>
Content-Type:
multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf"
Content-Disposition:
inline
On Sun, Dec 28, 2003 at 11:34:37PM +0000, Henning Makholm wrote:
Scripsit Steve Greenland <steveg@moregruel.net>
On 27-Dec-03, 17:28 (CST), Henning Makholm <henning@makholm.net> wrote:
The non-tecnical issue - namely his attempts to threaten Enrico into
submission by abusing his BTS power rather than explaining why he
thinks as he does *is* in my book completely unreasonable.
Why is that a problem, yet Enrico's attempt to bludgeon AJ into
submission by repeatedly re-opening a wish-list item
How can a wishlist item be used to "bludgeon" in any way?
I have asked this repeatedly and not yet gotten any answer.
Reopening a bug report that the maintainer has closed, when it is clear
the maintainer disagrees with you (and isn't merely mistaken on
technical grounds) interferes with the maintainer's ability to manage
his package's open bug reports through the BTS, and is thus an act of
coercion. You may have different views on whether and when such acts of
coercion are justified, but there should be no question that this *is*
coercive, and there should also be no room for surprise when attempts to
coerce backfire.
Closing the "bug" is one acceptable way to do so.
There is a "wontfix" tag for that. Rather, closing the wishlis itemt
is a way of asking the submitter to acknowlege that his request was
silly in the first place. Refusing to let the submitter *not*
acknowledge this, under threat of BTS exclusion, is repression of the
submitter's right to have his own thoughts about the issue.
The default web view of the BTS data for a package doesn't hide
"wontfix" bugs. Leaving such bugs open perpetually only because the
submitter disagrees with the maintainer sounds like a good way to make
the BTS unuseable from dialup connections, and unassailable by would-be
Samaritans casually perusing the site.
------------------------------------------------------------------------
Subject:
Re: Linux 2.6.0
From:
Andres Salomon <dilinger@voxel.net>
Date:
Sun, 28 Dec 2003 20:55:05 -0500
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] pan.2003.12.29.01.55.03.540063@voxel.net>
Content-Type:
text/plain; charset=ISO-8859-1
Content-Transfer-Encoding:
8bit
On Sun, 28 Dec 2003 15:50:26 +0100, Robert Millan wrote:
On Sat, Dec 27, 2003 at 08:32:01PM +0100, Michael Meskes wrote:
That bit sounds like worthwile.. but I'd still need a more general description
of what the patches do. I'm concerned about incompatibilities with other
Actually I see the problem that this is not a single patch but quite a
lot of patches merged.
Sort of like a fork, then.. that's a showstopper. I can't apply a patch that
contains a lot of merged patches without analising what each of them does.
It is; it's similar to the old 2.4 -ac trees that Alan Cox used to
maintain. Andrew's tree is a testing ground for various experimental
2.6 patches; if they prove stable, they get merged into Linus' 2.6 tree.
Of course, I find the -mm tree to be more usable in general, because
bugfixes are integrated into it quicker than w/ Linus' tree. OTOH, bugs
tend to pop up, but Andrew is pretty good about dropping buggy patches
quickly.
That's how it's been for 2.5 and 2.6 so far; things may change once Andrew
becomes the 2.6 maintainer.
If someone splits the part we're interested in, it could be added to my
package, but then I'd see no reason why it couldn't be added to
Herbert's kernel-patch-debian-2.6.0 (which my package uses) or even
merged in upstream.
The important patches will be merged upstream. I would recommend
providing the -mm tree only if you're willing to keep up w/ the pace that
he does releases; they tend to be made a lot quicker than Linus releases.
------------------------------------------------------------------------
Subject:
bug #151273: linneighborhood: package name spelt wrong
From:
Will Lowe <harpo@thebackrow.net>
Date:
Sun, 28 Dec 2003 18:05:37 -0800
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 20031229020537.GB27289@thebackrow.net>
Content-Type:
text/plain; charset=us-ascii
Content-Disposition:
inline
Any opinions on the right way to deal with this? The submitter
searched for "linneighbourhood" but upstreem clearly spells it
"neighborhood".
Perhaps just a Provides: linneighbourhood? Or close the bug?
------------------------------------------------------------------------
Subject:
Re: Bug#224742 acknowledged by developer (Re: Bug#224742: Related to
this issue...)
From:
Henning Makholm <henning@makholm.net>
Date:
29 Dec 2003 01:05:04 +0000
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 87vfo0o2m7.fsf@kreon.lan.henning.makholm.net>
Content-Type:
text/plain; charset=ISO-8859-1
Content-Transfer-Encoding:
8bit
Scripsit Martin Loschwitz <madkiss@debian.org>
I really don't get why you want to blame aj.
Becauses he uses BTS ownership to blugeon people into submission?
In my opinion, he perfectly fulfills his jobs as release manager:
Avoid news bug reports means making a release possible sooner. Yay
for aj!
Wishlist items should have no bearing at all on when a release becomes
possible.
------------------------------------------------------------------------
Subject:
Re: Bug#224742: Related to this issue...
From:
Henning Makholm <henning@makholm.net>
Date:
29 Dec 2003 02:02:32 +0000
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 87n09cnzyf.fsf@kreon.lan.henning.makholm.net>
Content-Type:
text/plain; charset=ISO-8859-1
Content-Transfer-Encoding:
8bit
Scripsit Colin Watson <cjwatson@debian.org>
Er, no, that's obviously not the case. Closed bugs remain publicly
archived forever,
But they stay nicely hidden from the unsuspecting public, right?
There is a "wontfix" tag for that. Rather, closing the wishlis itemt
is a way of asking the submitter to acknowlege that his request was
silly in the first place.
No, it's no such thing.
What is it, then, if not a way of hiding the problem, as regards the
default public listing for the package?
(I note that Anthony's talk of exclusion applies strictly and only
to control@bugs, as far as I know; not that I necessarily agree with
his actions, but I'd rather stay out of that.
But that is what the (sub)thread is about!?
If you think that access to control@bugs is required in order to
have your own thoughts about an issue then I'm sorry to say that
you're mad.)
Of course I don't think so. The BTS exclusion threat was just a weapon
that happened to be at hand for the maintainer when he wanted to force
Enrico into submission.
Ultimately, a maintainer's bug list belongs to the maintainer,
subject to review by the Technical Committee.
The Tecnical Committee is known to want nothing to do with BTS
procedures; see #97671. Curiously, in that case Anthony Towns seemed
to be far from thinking that bug lists belong to the maintainer.
Perhaps the true principle is that bug lists belong to whomever holds
the BTS-exclusion gun (or other appropriately large artillery)?
(The gun was drawn, but apparently not fired, in
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=97671&msg=107>).
The submitter did not wish to appeal - just to go on record as
disagreeing.
And he has quite adequately done so, and could have done so simply by
sending more information to the bug report.
Possibly. But he happened to want his wishes to stay public. Is that
such a very bad thing that it justifies being threatened with BTS
excusion?
I think your talk of thought control is a gross overreaction.
Possibly. Image control, then.
------------------------------------------------------------------------
Subject:
Re: Bug#224742: Related to this issue...
From:
Henning Makholm <henning@makholm.net>
Date:
29 Dec 2003 02:13:19 +0000
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 87isk0nzgg.fsf@kreon.lan.henning.makholm.net>
Content-Type:
text/plain; charset=ISO-8859-1
Content-Transfer-Encoding:
8bit
Scripsit Steve Langasek <vorlon@netexpress.net>
On Sun, Dec 28, 2003 at 11:34:37PM +0000, Henning Makholm wrote:
How can a wishlist item be used to "bludgeon" in any way?
Reopening a bug report that the maintainer has closed, when it is clear
the maintainer disagrees with you (and isn't merely mistaken on
technical grounds) interferes with the maintainer's ability to manage
his package's open bug reports through the BTS,
How? Does it somehow stop the maintainer from closing items that are
genuinely resolved, or setting tags, or adjusting titles or severities?
and is thus an act of coercion.
The fact that the wishlish item is listed by the BTS in no way forces
the maintainer to do or not do anything. Thus it cannot be coercion.
You may have different views on whether and when such acts of
coercion are justified,
No, I do not recognize any act of coercion here at all. The
maintainer's freedom to act or not act as he pleases is in no way
affected by the existence of an open wishlist item.
but there should be no question that this *is* coercive,
Evidently, you're wrong. There is lots of question, and I still do not
see any coercive effect whatsoever.
------------------------------------------------------------------------
Subject:
Re: apt 0.6 in experimental
From:
"Nathaniel W. Turner" <nate@houseofnate.net>
Date:
Sun, 28 Dec 2003 21:35:35 -0500
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 200312282135.35801.nate@houseofnate.net>
Content-Type:
text/plain; charset="iso-8859-1"
Content-Transfer-Encoding:
7bit
Content-Disposition:
inline
On Sunday 28 December 2003 19:11, Matt Zimmerman wrote:
1. Use dists/<dist>/Release for both purposes (authentication and
pinning). This is trivial, and works fine for the Debian archive
(dists/<dist>/Release is more or less a superset of
dists/<dist>/<section>/<binary,source>/Release), but could have unknown
effects for third-party repositories which provide per-section Release
files.
After discussing this with Colin Walters, I've implemented (1.) in apt
0.6.4, which has been uploaded to experimental.
So, as a 3rd-party repository maintainer who wants to provide signed Release
files, I should (eventually) get rid of my dists/<dist>/<section>/
<binary,source>/Release files (since future versions of apt will ignore them)
and create dists/<dist>/Release files? Do I understand this correctly?
Presumably the Component and Architecture fields of the Release file will
become obsolete?
This is not a problem for me; I just want to be sure I understand things
correctly. =)
Cheers,
nate
------------------------------------------------------------------------
Subject:
Re: apt 0.6 in experimental
From:
Joey Hess <joey@kitenet.net>
Date:
Sun, 28 Dec 2003 22:32:17 -0500
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 20031229033217.GA11995@kitenet.net>
Content-Type:
multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp"
Content-Disposition:
inline
Matt Zimmerman wrote:
On Sun, Dec 28, 2003 at 02:28:18PM -0800, Matt Zimmerman wrote:
apt 0.5 downloads dists/<dist>/<section>/<binary,source>/Release for use in
policy calculations. apt 0.6 does not download that file at all, and
downloads dists/<dist>/Release for use in authentication. However, 0.6
still tries to read dists/<dist>/<section>/<binary,source>/Release, which
has not been downloaded.
This could be fixed one of two ways:
1. Use dists/<dist>/Release for both purposes (authentication and pinning).
This is trivial, and works fine for the Debian archive (dists/<dist>/Release
is more or less a superset of
dists/<dist>/<section>/<binary,source>/Release), but could have unknown
effects for third-party repositories which provide per-section Release
files.
2. Continue to download them all. This requires some further changes to the
apt-secure code.
Personally, I find the distinction between these two types of Release files
to be confusing, and would prefer (1) as it is much simpler. However, I
don't know whether there is a rationale for why things were done as they
were for apt-secure, and whether the top-level Release file is intended to
replace the others.
After discussing this with Colin Walters, I've implemented (1.) in apt
0.6.4, which has been uploaded to experimental.
Somewhat offtopic, but is there any documentation of the format and
fields in Release files anywhere at all? Or did they spring full-fledged
(and undocumented) from the sweaty brows of Aj and Jason? :-)
------------------------------------------------------------------------
Subject:
Re: Bug#224742: Related to this issue...
From:
Steve Langasek <vorlon@netexpress.net>
Date:
Sun, 28 Dec 2003 21:35:01 -0600
To:
debian-devel@lists.debian.org
To:
debian-devel@lists.debian.org
Message-ID:
<[🔎] 20031229033501.GD14732@quetzlcoatl.dodds.net>
Content-Type:
multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="XWOWbaMNXpFDWE00"
Content-Disposition:
inline
On Mon, Dec 29, 2003 at 02:02:32AM +0000, Henning Makholm wrote:
Ultimately, a maintainer's bug list belongs to the maintainer,
subject to review by the Technical Committee.
The Tecnical Committee is known to want nothing to do with BTS
procedures; see #97671. Curiously, in that case Anthony Towns seemed
to be far from thinking that bug lists belong to the maintainer.
Perhaps the true principle is that bug lists belong to whomever holds
the BTS-exclusion gun (or other appropriately large artillery)?
Some things are the maintainer's prerogative, and some are not.
Deciding whether a bug is release-critical is not a maintainer's
prerogative; nor is closing bug reports for outstanding RC issues.
Closing out wishlist bugs that the maintainer disagrees with, OTOH, *is*
a maintainer's prerogative.