Your message dated Thu, 22 Mar 2001 02:30:25 -0500
with message-id <[EMAIL PROTECTED]>
and subject line Bug#90511: proposal] addressing objections (re: disallow
multi-distribution uploads)
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.)
Darren Benham
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 21 Mar 2001 04:06:08 +0000
>From [EMAIL PROTECTED] Tue Mar 20 22:06:08 2001
Return-path: <[EMAIL PROTECTED]>
Received: from ppp41.ts6-2.newportnews.visi.net (blimpo.internal.net)
[209.8.199.41]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 14fZst-0004Jw-00; Tue, 20 Mar 2001 22:06:07 -0600
Received: from bmc by blimpo.internal.net with local (Exim 3.22 #1 (Debian))
id 14fZsp-0000qr-00
for <[EMAIL PROTECTED]>; Tue, 20 Mar 2001 23:06:03 -0500
Date: Tue, 20 Mar 2001 23:06:02 -0500
From: Ben Collins <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: [proposal] disallow multi-distribution uploads
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
Sender: Ben Collins <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
--fUYQa+Pmc3FrFX/N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Package: debian-policy
Summary:
Policy should disallow uploads for multiple distributions. Specifically
this means same version uploads to "stable unstable".
History:
Running a buildd, I have the problem of builds that come in for stable
and unstable. Currently this means the buildd performs the compile on
stable, and either uploads to "stable unstable", or as it were
previously, it uploaded to stable, and then asked the buildd admin to
perform the same upload to unstable. That used to work, and it used to
be a needed feature for "frozen unstable" uploads. We do not support
this anymore, since we do not have a "frozen" dist to upload to.
Also, dinstall (AKA katie), disallows seperate uploads of the same
version to seperate distributions. The pool layout means there is only
one copy of the same version, and the pgsql database tracks which
distribution this is supposed to be in.
It's my opinion that same version uploads to stable/unstable are harful
to archive and distribution integrity. I've talked this over with James
Troup, and he seems to agree with the points below, and is considering
enforcing them via dinstall checks. My intention is to get the weight
of policy behind this.
Technical reasoning:
1) Building for "stable unstable" means that 99% of the time the build
is performed on a box running "stable". So the package will be compiled
against "stable" libraries. Now we all know that most of the major
libraries will go on to new major versions between releases. Ncurses (4
to 5 between slink and potato), readline (2 to 4 between slink and
potato), gnome (several revisions during potato development, and others
now), libstdc++ (which changes with the libc6 major upgrades), etc...
Now, a lot of libraries keep an oldlib around for backward compatibility
of packages that have not been recompiled for the newest version of the
lib. This is a less than optimal situation since it must be maintained
just like any other package. If libncurses4 is in stable, and
libncurses5 is in unstable (with the 4 version around only for backward
compat), then builds in unstable should be using the libncurses5.
However, someone compiling for "stable unstable" uneedingly prolongs
this oldlib's life.
2) Policy changes. This is probably the worst case. We all know that
policy abiding build-helpers change between releases just like policy
does. Take the usr/doc->usr/share/doc changeover scripts, and the X
default scripts used and hardcoded during the build. Building on stable
and unstable produces 2 different packages, abiding by two different
policies.
So by allowing stable built apps into unstable, we prolong policy
changes for the distributions aswell.
3) Build failures. It is commonly the case that a package built on
stable will not compile on unstable, even though it works runtime wise.
Issues:
The only issue I forsee is the likely even of where an upload to stable
and unstable is desired. I suggest that policy specify this to be done:
If package "blah" is in stable/unstable of version 1.0-1 (meaning it has
not changed since stable was released) and an upload must be done for
both stable and unstable of 1.0-2, then the stable upload must be
1.0-1.90 and unstable must be 1.0-2. This is similar to an NMU. The
reason for the .90 is similar in spirit to how glibc starts a
pre-release series (IOW, pre-releases for 2.2 start at 2.1.90).
Caveats:
This policy in no way forces compiled for unstable to be against the
unstable dist. IOW, uploading to unstable does not mean it was compiled
against unstable. That is a little harder to enforce. Perhaps we need a
way to tell dinstall that certain deps are obsoleted for a dist (IOW,
tell dinstall that packages targeted for unstable cannot dep on
libncurses4). However, that is another proposal altogether, and is not
the aim of this one.
--=20
-----------=3D=3D=3D=3D=3D=3D=3D-=3D-=3D=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=
=3D=3D=3D-----------=3D=3D=3D=3D=3D------------=3D-=3D------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] '
`---=3D=3D=3D=3D=3D=3D=3D=3D=3D------=3D=3D=3D=3D=3D=3D=3D-------------=3D=
-=3D-----=3D-=3D=3D=3D-=3D=3D=3D=3D=3D=3D-------=3D--=3D---'
--fUYQa+Pmc3FrFX/N
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Ben Collins <[EMAIL PROTECTED]>
iD8DBQE6uCiqfNc/ZB4E7C0RAqXwAJ497nIUFnhGOwZYk4IP+5Zs80kUnACfWhlk
E021fm/qqHcgPmRQP+Uk/MQ=
=eV4C
-----END PGP SIGNATURE-----
--fUYQa+Pmc3FrFX/N--
---------------------------------------
Received: (at 90511-done) by bugs.debian.org; 22 Mar 2001 07:30:27 +0000
>From [EMAIL PROTECTED] Thu Mar 22 01:30:27 2001
Return-path: <[EMAIL PROTECTED]>
Received: from cc551902-b.indnpls1.in.home.com (apocalypse.deadbeast.net)
[24.183.211.35] (postfix)
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 14fzYB-0000aX-00; Thu, 22 Mar 2001 01:30:27 -0600
Received: by apocalypse.deadbeast.net (Postfix, from userid 1000)
id 414D76700C; Thu, 22 Mar 2001 02:30:25 -0500 (EST)
Date: Thu, 22 Mar 2001 02:30:25 -0500
From: Branden Robinson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Bug#90511: proposal] addressing objections (re: disallow
multi-distribution uploads)
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Thu, Mar 22, 2001
at 12:11:43AM +0100
Mail-Copies-To: nobody
X-No-CC: I subscribe to this list; do not CC me on replies.
Delivered-To: [EMAIL PROTECTED]
--pf9I7BMVVzbSWLtt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Mar 22, 2001 at 12:11:43AM +0100, Santiago Vila wrote:
> "First they forbid source-only uploads, but since I did not do
> source-only uploads I didn't care. Then they forbid uploads to
> `stable unstable', but since I didn't do such uploads I didn't care either
> [...]". Does this ring a bell?
Yeah. And I remember the original version.
Godwin has been invoked. You lose.
--=20
G. Branden Robinson | I am sorry, but what you have mistaken
Debian GNU/Linux | for malicious intent is nothing more
[EMAIL PROTECTED] | than sheer incompetence!
http://www.debian.org/~branden/ | -- J. L. Rizzo II
--pf9I7BMVVzbSWLtt
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjq5qhAACgkQ6kxmHytGony8tgCfSlHcjYAqi3IacmcRVZGLAPM7
a3EAn34jpW7MO6hgLLDr3kNIGGMRXVKT
=5ycg
-----END PGP SIGNATURE-----
--pf9I7BMVVzbSWLtt--
