Bug#90511: proposal] disallow multi-distribution uploads
On Wed, Mar 21, 2001 at 12:45:31PM -0500, Ben Collins wrote:
> On Wed, Mar 21, 2001 at 12:19:02AM -0500, Branden Robinson wrote:
> > On Tue, Mar 20, 2001 at 11:06:02PM -0500, Ben Collins wrote:
> > > Summary:
> > > History:
> > > Technical reasoning:
> > > Issues:
> > > Caveats:
> >
> > But nowhere did you have the actual text of a policy change. This is
> > needed.
> >
> > Please write one up and I'll second it.
>
> Right, here it is.
>
> diff -urN debian-policy-3.5.2.0.orig/policy.sgml debian-policy-3.5.2.0/policy.sgml
> --- debian-policy-3.5.2.0.orig/policy.sgml Sun Feb 18 09:37:35 2001
> +++ debian-policy-3.5.2.0/policy.sgml Wed Mar 21 12:44:48 2001
> @@ -1400,8 +1400,8 @@
>
> <p>
> In a <tt>.changes</tt> file or parsed changelog output
> - this contains the (space-separated) name(s) of the
> - distribution(s) where this version of the package should
> + this contains the name of the
> + distribution where this version of the package should
> be or was installed. Distribution names follow the rules
> for package names. (See <ref id="f-Package">).
> </p>
> @@ -1434,15 +1434,23 @@
> </p>
> </item>
>
> - <tag><em>frozen</em></tag>
> + <tag><em>testing</em></tag>
> <item>
> <p>
> - From time to time, the <em>unstable</em>
> - distribution enters a state of `code-freeze' in
> - anticipation of release as a <em>stable</em>
> - version. During this period of testing only
> - fixes for existing or newly-discovered bugs will
> - be allowed.
> + Testing is a psuedo distribution that is a
s/psuedo/pseudo/
shouldn't it really be 'the' culmination and not 'a'.
> + culmination of the previous <em>stable</em> release
> + with select packages from <em>unstable</em> applied
> + to it. The packages have to meet certain criteria in
> + order to migrate from <em>unstable</em> into
> + <em>testing</em>. Some of these criteria include being
and you list 'some' but don't give any hints as to where the
others are specified
great, add MORE vaguness to policy.
please specify where the rest of the 'criteria' can be obtained
perhaps something like 'the release manager may impose additional
criteria on packages to determine whether they enter testing
at his discretion'
perhaps not the release manager, whomever, wherever.
somewhere.
> + compiled on all supported architectures, no open
> + release critical bugs and no dependencies on
> + packages that are not in <em>testing</em> already
> + (which may fail some of these criteria). Also, there
> + is a time constraint before migration. Note, you cannot
> + upload directly to <em>testing</em> as you can with
> + <em>stable</em> and <em>unstable</em>. This distribution
> + is the base for the next planned release.
> </p>
> </item>
>
> @@ -1493,12 +1501,26 @@
> Distribution.</p>
> </item>
>
> - </taglist> You should list <em>all</em> distributions that
> - the package should be installed into. Except in unusual
> - circumstances, installations to <em>stable</em> should also
> - go into <em>frozen</em> (if it exists) and
> - <em>unstable</em>. Likewise, installations into
> - <em>frozen</em> should also go into <em>unstable</em>.
> + </taglist>
> + You should list <em>only</em> the distribution that the
> + package was compiled for. Do not upload to multiple
> + distributions. Currently it is only possible to upload to
> + <em>stable</em>, <em>unstable</em> or <em>experimental</em>.
> + If an upload needs to go to both <em>stable</em> and
> + <em>unstable</em>, then they must be uploaded seperately,
> + and with different version numbers, the <em>stable</em>
> + version being less than the <em>unstable</em> one.
> + <p>
> + One example of this is if the current version of the
> + <em>stable</em> and <em>unstable</em> package is 1.2-1, then
> + a new upload can have 1.2-1.90 for <em>stable</em> and 1.2-2 for
> + <em>unstable</em>. Each should be compiled on that
personally I prefer the foo-1.2-1.potato.1 notation
(The name of the distr, not 'stable', since what 'stable' is
changes.)
i always thought incremental debian revisions were for NMU's?
i have been wrong before (once).
> + particular distribution, so that it abides by the policy
> + of that distribution, so it will use the latest libraries
> + available on that distribution, and so it will be in sync with
why make it mandatory that packages be compiled with the 'latest'
libraries available??
i can certainly see many situations where this is desirable, yet
many where it would be a bother/irrelevant.
make things mandatory, and taking away discretion from people
just mucks things up.
> + what the autobuilders for the other architectures produce (they
> + always build on the latest version of a particular
> + distribution).
> </footnote>
> </p>
> </sect1>
> @@ -1997,7 +2019,7 @@
> <p>
> That format is a series of entries like this:
> <example>
> - <var>package</var> (<var>version</var>) <var>distribution(s)</var>; urgency=<var>urgency</var>
> + <var>package</var> (<var>version</var>) <var>distribution</var>; urgency=<var>urgency</var>
>
> * <var>change details</var>
> <var>more change details</var>
> @@ -2013,7 +2035,7 @@
> </p>
>
> <p>
> - <var>distribution(s)</var> lists the distributions where
> + <var>distribution</var> lists the distribution where
> this version should be installed when it is uploaded - it
> is copied to the <tt>Distribution</tt> field in the
> <tt>.changes</tt> file. See <ref id="f-Distribution">.
--
Brian Russo <brusso@phys.hawaii.edu>
Debian/GNU Linux <wolfie@debian.org> http://www.debian.org
LPSG "member" <wolfie@lpsg.org> http://www.lpsg.org
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Reply to: